Nathan C Summers <[EMAIL PROTECTED]> writes:

> Some horrible kludge could also be dreamed up involving GTKPlugs.  That 
> would move the windowing system dependance down to the GDK level, but 
> would also make things ineligant, and it would be difficult to get it to 
> work in all cases, especially with an unreliable plug-in.

GtkPlug is an X11-only thing just as GtkSocket; it is not implemented
on any other platform that GDK has been ported to.

> The only problem with this solution is that the api that in-process and 
> out-of-process components of the GIMP, while similar in nature, are 
> slightly different, especially in terms of the names of the functions 
> used.  These differences will have to be reconciled, either by making the 
> functions have the same names, or by writing some kind of wrapper such 
> that they can be used by either.

IMO the tool API needs to be reviewed anyway. I'm definitely all for 
pluggable tools. For the moment I thought about paint tools mainly. 
Is that what you had in mind too or did you think tools in general?

I very much welcome your idea, but I think before any such code is 
written, we should solve the remaining issues in the tools system.
That is mainly GUI/functionality separation. There needs to be a way 
for the tools to register their parameters so that GIMP's GUI can
choose from a bunch of generic tool info widgets and create a tool
info dialog. Then, no tool should use any GTK+/GDK functions nor 
should it receive GDK events directly. Once this separation (that
we've already started) is completed, we should have a reasonable
tool API and it should be easy to define an interface that can be
exported in order to allow plug-in and module tools.

Salut, Sven
Gimp-developer mailing list

Reply via email to