I'm sorry that I haven't been able to do much GIMP participation in the last several months. I don't want to bore everyone here with details of my personal life, so suffice it to say I haven't been able to spend much time hacking or even replying to email. I regret any inconvenience this has caused. The last time I checked, in-process tool plugin loading worked with only a handful of mild issues to be resolved. I have no doubt that it can be in perfect working order in less than two weeks. Out-of-process tool plug-ins are an entirely different matter. Implementing them would still require a fair amount of work. It would also involve some changes to the gimp protocol which, while I would not really term them to be kludgy, add more complexity in places they shouldn't be. Given our time constraints, that in-process tool plug-ins already work, and that out-of-process tool plug-in communication can be handled much more cleanly in libpdb (which I sincerly hope will be used in GIMP 2.0), I would not be opposed to the removal of out-of-process tool plug-ins from the list of goals for 1.4. While I still believe that out-of-process tool plug-ins are the Right Thing to do, they can wait for 2.0. Regardless of whether out-of-process tool plug-ins make it in 1.4, I now feel that the best developmental proceedure is to make in-process tool plug-ins work as well as possible. Without further ado, here is a list of things that must be done to make tool plug-ins useful: * the loop in tools.c that loads tool modules should be uncommented and moved before the loading of the built-in tools, so that they appear last in the toolbox. (perhaps it would be good to allow tools to be reordered by the user.) * cheesey_module_loading_hack needs to stop leaking memory and handle errors sanely. It could also use a better name. * a dialog box should be able to show the tool modules loaded, and tool modules shoulde be loadable and unloadable at runtime. Specifically, any tool not currently being used should be unloadable. That would make tool plug-in development significantly less painful. The current module dialog would be a sensible location for this additional functionality. * tool plug-ins need the ability to supply a custom icon. Themes should be able to supply a replacement if they "know about" that particular tool plug-in. * likewise, tool plug-ins should be able to supply their own mouse cursors. * the back-end pixel-crunching code usable by both the gui and pdb interfaces should be better separated from the interface-specific code. I have long felt that the paint tool refactoring is a good example of how this can be better accomplished, and feel that similar measures would be useful in the rest of the tools. * tool plug-ins need a mechanism to expose their functionality to the PDB. I will file these items in Bugzilla if consensus is that this is the best course of action. I look forward to your comments. Respectfully, Rockwalrus
