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

_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to