While I was working on the list of parasites (which is more than one week late, sorry), I started thinking about the changes to the PDB or to the plug-in API that have been discussed on this list or submitted to bugzilla.gnome.org. Here is a summary of the changes that I still have in mind (please tell me if I have forgotten something). It would be interesting to have a look at this list and start discussing what should be in 1.3.x, what should wait until 2.x, and what will be postponed for a later release. A bit of discussion and planning would be interesting because most of these changes will break many plug-ins.
Changes in the core that will probably have an impact on the plug-ins, but for which a backwards-compatible workaround is possible (so that old plug-ins can still run if they do not need the new features): - Use the PDB for all interactive tools. All actions that can be performed by clicking somewhere in the image window (painting, selecting, picking a color, moving guides, panning, zooming, ...) must be able to trigger a PDB call. This is necessary in order to implement a macro recorder (bug #51937). - Support channels that have more than 8 bits: 12 bits, 16 bits or float. This will probably wait until GIMP 2.0 (using GEGL). There should probably be an option that allows a plug-in to declare the type of channels that it supports when it registers itself to the PDB. The GIMP could assume that all plug-ins that do not specify this option can only support 8 bits per channel and would then avoid calling these plug-ins if the current drawable has a different depth. - Support for vector layers (and tools for manipulating them). This is requested by many users, but this is a lot of work. This feature has to be designed carefully before being implemented and I do not know if anyone is currently planning to spend enough time on this. The compatibility with the old plug-ins could be preserved by using the same method as above. (see also bug #68915 and bug #61786)
Changes that will certainly break all old plug-ins: - Use named parameters for the PDB. Instead of using positional parameters, all PDB calls could take a list of name=value pairs, in which each name is a string. This would make it easier to extend some plug-ins or functions later without breaking all scripts that call these functions. But this would break all plug-ins and scripts in the meantime, and this will have some performance impact if the core calls (e.g., brush strokes) going through the PDB (for the macro recorder) are also using named parameters. - Use types in parasites. Currently, it is not possible to know if the data stored in a parasite is an integer, a readable string or some raw binary data. Adding a "type" parameter (only for simple scalar types) would enable the GIMP to detect some inconsistencies automatically and it would also allow a parasite editor to work better. This would break all plug-ins that are using parasites.
Changes that will break only the file (load/save) plug-ins: - Add a PDB function to save a thumbnail, and require the Save plug-ins to call this function when an image is saved. This is necessary to solve bug #25272, because in some cases the core has no idea of what will be saved in the file (if Export is used) and the plug-in is the only part of the code that can generate a correct thumbnail. (The core will still be responsible for saving the thumbnail and respecting the user's preferences, but the plug-in should decide when the image or drawable is ready to be used.) - Add a "file fragment" parameter when calling a plug-in. In addition to the name of the file to be loaded/saved, the plug-in could get the name of a fragment, so that only the corresponding part of the file is loaded or modified. Although some fragments could be handled by a VFS layer (e.g., files inside a tar archive), some others can only be understood correctly by the plug-in itself (e.g., page in a multi-page image file, indexed bitmap in a DOOM WAD file for which the color palette has to be loaded implicitely, etc.). So there should be a way to pass the fragment name in addition to the file name so that the same part of a multi-image file can be loaded and then saved later. Most plug-ins would just use NULL.
Changes that will break only the "filter" plug-ins: - Add a parameter (or a separate PDB call) that allows a plug-in to submit an icon when registering itself to the PDB. This icon would be shown in the menus, next to the name of the plug-in. Adding a new PDB call instead of requiring an additional parameter during the registration would preserve the compatibility with the old plug-ins but could cause some problems if that new function is called twice, called after the initialization, or called by another plug-in giving a reference to the wrong menu entry (copy and paste error).
Did I forget anything that will or may have an impact on the plug-ins?
As you can see from this list, it is likely that some or all plug-ins will have to be modified at some point in time, and maybe more than once. We should discuss this and decide when this should happen (or if it should happen at all).
-Raphael
