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.
Gimp-developer mailing list