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

* 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.


Gimp-developer mailing list

Reply via email to