Hi, Nathan C Summers <rockwlrs@xxxxxxxxxx> 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
