On 17 Dec 2001, Sven Neumann wrote: > 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. Oh yes, I remember that now. After I rejected GtkPlug I forgot all the reasons why. :) I'm disapointed they didn't make it more windowing system agnostic. Windows, at least, is perfectly capible of something like GtkPlug/GtkSocket. > > 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? Well, tools in general, although the paint tools are an important enough subset that they probably could benefit from special-case treatment. > 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. I agree completely. > 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. I agree to this as well. What specifically do you have in mind to replace the current system of sending the (essentiall) raw GtkEvent to the tool? I thought about them having an identical interface with the PDB to reduce the amount of code needed, but really, scripting and interactive work is different enough that the interfaces that a different interface is needed. Also, I though about making the PDB interface to all tools identical, but the PDB intefaces are really much useable as they are. Rockwalrus
