PDB and Plug-In Refactoring

One of the last remaining bits of antique code in the GIMP are the parts that talk to plug-ins, namely the plug-in handling code itself, and the PDB (procedural database) which provides a way for plug-ins to call GIMP’s internal functionality and which keeps all procedures provided by plug-ins.

Everything was organized around some crufty C-structs, lived in files without proper namespace, and was basically untouched by all the refactoring that was happening during the last few years. To illustrate the evilness: the PDB did not even really know which of its procedures were dynamically allocated, and which were constant structs that are defined at compile time (not to speak of the part where perl code generated perl code that generated perl code that…). This had to stop.

Right after LGM, I entered refactoring mode:

  • All the perl-that-generates-perl stuff had to die. Every procedure definition in the PDB files (tools/pdbgen/pdb/*.pdb, they are still perl) now looks the same: Inargs, Outargs, Code.
  • The homemade system to specify a procedure’s arguments and return values doesn’t exist any more. Everything is based on GParamSpec now. A lot of new GIMP-specific param specs was added in app/core/gimpparamspecs.c.
  • The procedure’s arguments from the same prehistoric era had to go too. Procedures now take and return everything as GValue, organized as GValueArray.
  • Procedures are GObjects now (app/pdb/gimpprocedure.c). Their memory-management was modernized a bit (they have memory management now). Plug-In procedures are a proper GimpProcedure subclass now (app/pdb/gimppluginprocedure.c), which made lots of code much more straightforward (they were separate structs before which had a pointer to the procedure they implement).
  • The PDB is now an object itself (app/pdb/gimppdb.c), instead of a bunch of global variables with some API around. The PDB instance emits signals when procedures are added or removed, so the GUI can for example create menu items for new plug-in procedures. No more direct calls from the core to the GUI via the ugly GUI-vtable.

The plug-in system is a similar mess, closely related to the PDB, but even worse. It has seen some refactoring, but just to the point where it was unavoidable to fix misbehavior or to get rid of calling deprecated GLib APIs. While the PDB cleanup has come a long way, I’m still in the middle of chopping and re-assembling the plug-in stuff:

  • Lots and lots of global variables have been moved to a new object, the GimpPlugInManager (app/plug-in/gimppluginmanager.c). Well they were not really global variables before, but members of the global Gimp instance, which is supposed to be the only “global” variable in the GIMP, but that doesn’t make much difference here.
  • Lots of functions are now methods of the GimpPlugInManager, which greatly helps finding them. Before, it was mostly unclear which function belonged to the plug-in instances themselves, and which to the infrastructure around that keeps is all together.

That’s where I am today, but there are still quite some hacks ahead before the stuff can be called “finished”:

The PlugIn struct (app/plug-in/plug-in.c) has to become an object, and this object needs some signals. Some code needs to listen to these signals, so cross-calling between unrelated scopes doesn’t happen any more. At some point people will even be able to understand how the plug-ins’ memory management is supposed to work 😉 Currently the calls to plug_in_ref() and plug_in_unref() are not really in places where one would expect them. I bet there is more uglyness that will go away as soon as I find it.

Now what are the benefits from all this work? Well, refactored code looks soooo much nicer 🙂

But seriously:

  • The refactored code does look nicer, is easier to read and understand, is easier to change and fix.
  • The PDB can check the passed arguments much better now. Thanks to GParamSpec GIMP can tell a plug-in/script developer which of the passed arguments was wrong in which way.
  • Every argument has a default value now. After GIMP 2.4 this will allow us to change the plug-in side of calling PDB procedures to something that has named parameters with default values. No more breaking scripts just becuase somebody added an optional argument.
  • (actually, optional arguments were impossible before).
  • Now that it’s all cleaned up, people != hardcore_longtime_developers can understand and change it.
  • And many other benefits that usually show up after the refactored code is in use for some time.

And now, please get GIMP from CVS and test it until it breaks. Then report the bug so the new PDB will be as solid as the old one.

2 Responses to “PDB and Plug-In Refactoring”

  1. Maurits Says:

    Cool stuff. Do I understand correctly that currently this won’t have an impact on the plug-in side, so that all current plug-ins keep working?

    After release 2.4 I will probably have to change some of my GIMP# code to benefit from this, right?

  2. Mitch Says:

    Yes and yes. And of course all current plug-ins will keep running also after 2.4, we will just have an additional way to specify procedure arguments and return values, and a way to call procedures that takes name-value pairs and allows to omit parameters.

Leave a Reply