Gimp/pdb
Jehan c8c8a68247 app, libgimp, pdb: deprecate various procedures in favor of filters.
I have manually tested each and every of the deprecated functions,
making sure we don't lose any feature. As expected, we don't. Having
dedicated libgimp functions may feel a tiny bit easier to call but this
is not scalable. We can't do this forever, with one function per filter.
And fortunately we won't have to, since now we can call filters on any
drawable directly! It also comes with the following generic advantages:

* It works with any filter, even third-party ones;
* We can also append filters non-destructively for later removal or
  edits (the deprecated functions were always merging the filters);
* If the filter evolves, e.g. with new arguments, it should not affect
  the API (though we should implement GEGL operation versions);
* If we don't need to set all arguments (e.g. leaving many args with
  default value), the filter API may even be simpler and shorter;
* The filter API will be much less "opaque" thanks to argument naming
  (rather than a long list of integers, doubles, etc.).

Specifically to the now deprecated functions, I noted the following
weaknesses on the deprecated API when testing:

* gimp_drawable_colorize_hsl() was missing a "color" argument;
* gimp_drawable_extract_component() had the enum argument "component"
  set as an integer, which is particularly opaque when re-reading
  existing code. Whereas the filter API uses generate choice strings
  which are self-explanatory! For instance choice RGB Red is 0 with the
  deprecated function but "rgb-r" with the filter API.
* gimp_drawable_levels() was missing "trc" argument (as noted in
  #15681).

And as expected, no features are lost.

Note that I didn't deprecate the curves functions yet, because we need
to implement the GimpCurve type in libgimp first.

There are a few more functions which I didn't deprecate yet, because
they don't use a filter directly, but some core functions, though for
some of them, it is very likely they can be efficiently reimplemented
with the filter API too. I'll have to look closer at it. It looks like
we may have to implement GimpHistogram in libgimp too though.
2026-02-01 22:31:02 +01:00
..
groups app, libgimp, pdb: deprecate various procedures in favor of filters. 2026-02-01 22:31:02 +01:00
app.pl pdb: better deprecated message, assuming it can be a function, GEGL op… 2026-02-01 22:31:02 +01:00
enumcode.pl Revert "pdb, libgimp: more #pragma once, and formatting cleanup" 2025-08-14 00:54:55 +02:00
enumgen.pl libgimp, pdb: (meson) fix building of libgimp/gimpenums.h inside the source tree. 2023-10-01 21:02:33 +02:00
enums-external.pl pdb: sync enums.pl generated file with source. 2024-11-24 20:34:43 +09:00
enums.pl text, libgimpbase: Move text enums 2025-10-08 11:34:57 +00:00
groups.pl app, libgimp, pdb: port GimpRasterizable interface to libgimp too. 2025-10-13 16:37:25 +02:00
lib.pl pdb: better deprecated message, assuming it can be a function, GEGL op… 2026-02-01 22:31:02 +01:00
meson-enumcode.py tools: Port meson-mkenums.sh to Python 2025-04-17 09:39:08 -03:00
meson-enumgen.py tools: Port meson-mkenums.sh to Python 2025-04-17 09:39:08 -03:00
meson-pdbgen.py tools: Port meson-mkenums.sh to Python 2025-04-17 09:39:08 -03:00
meson.build app, libgimp, pdb: port GimpRasterizable interface to libgimp too. 2025-10-13 16:37:25 +02:00
pdb.pl app, libgimp, pdb: port GimpRasterizable interface to libgimp too. 2025-10-13 16:37:25 +02:00
pdbgen.pl app, libgimp, pdb, plug-ins: array size's type should be gsize. 2024-10-25 23:28:42 +02:00
README
README_NEW_PDB_PROC app, libgimp*, pdb, themes: Fix description typos 2025-09-24 16:50:15 +00:00
stddefs.pdb pdb: Add procedures to inspect filter operations 2025-08-03 21:38:28 +00:00
util.pl

Some mostly unfinished docs are here.

-Yosh

This document describes the tool PDBGEN.

If you added or modified .pdb files do not run this tool manually but
run make instead! It will call pdbgen.pl then to generate the files
into the right output directories.

PDBGEN
------------------

What is this?
PDBGEN is a tool to automate much of the drudge work of making PDB interfaces
to GIMP internals. Right now, it generates PDB description records,
argument marshallers (with sanity checking) for the app side, as well
as libgimp wrappers for C plugins. It's written so that extending it
to provide support for CORBA and other languages suited to static
autogeneration.

Invoking PDBGEN from the command line:
1. Change into the ./pdb directory.
2. $ ./pdbgen.pl DIRNAME
where DIRNAME is either "lib" or "app", depending on which set of files
you want to generate. The files are written into $destdir/app or $destdir/libgimp.
$destdir is the environment variable destdir. If it's not set,
then it's the ./pdb directory. Make sure the directories
$destdir/app and $destdir/libgimp already exist and you have write permissions.
Otherwise the code generator will fail and exit.
It's up to you to diff the file you changed. When you're happy with
the generated file, copy it into the actual ./app/ or ./libgimp/ directory
where it finally gets built.

Anatomy of a PDB descriptor:
PDB descriptors are Perl code. You define a subroutine, which corresponds
to the PDB function you want to create. You then fill certain special
variables to fully describe all the information pdbgen needs to generate
code. Since it's perl, you can do practically whatever perl lets you
do to help you do this. However, at the simplest level, you don't need
to know perl at all to make PDB descriptors.

Annotated description:
For example, we will look at gimp_display_new, specified in gdisplay.pdb.

sub display_new { 

We start with the name of our PDB function (not including the "gimp_" prefix).

    $blurb = 'Create a new display for the specified image.';

This directly corresponds to the "blurb" field in the ProcRecord.

    $help = <<'HELP';
Creates a new display for the specified image. If the image already has a
display, another is added. Multiple displays are handled transparently by the
GIMP. The newly created display is returned and can be subsequently destroyed
with a call to 'gimp-display-delete'. This procedure only makes sense for use
with the GIMP UI.
HELP

This is the help field. Notice because it is a long string, we used HERE
document syntax to split it over multiple lines. Any extra whitespace
in $blurb or $help, including newlines, is automatically stripped, so you
don't have to worry about that.

    &std_pdb_misc;

This is the "author", "copyright", and "date" fields. Since S&P are quite
common, they get a special shortcut which fills these in for you. Stuff
like this is defined in stddefs.pdb.

    @inargs = ( &std_image_arg );

You specify arguments in a list. Again, your basic image is very common,
so it gets a shortcut.

    @outargs = (
        { name => 'display', type => 'display',
          desc => 'The new display', alias => 'gdisp', init => 1 }
    );

This is a real argument. It has a name, type, description at a minimum.
"alias" lets you use the alias name in your invoker code, but the real
name is still shown in the ProcRecord. This is useful not only as a
shorthand, but for grabbing variables defined somewhere else (or constants),
in conjunction with the "no_declare" flag. "init" simply says initialize
this variable to a dummy value (in this case to placate gcc warnings)

    %invoke = (
        headers => [ qw("gdisplay.h") ],

These are the headers needed for the functions you call.

        vars => [ 'guint scale = 0x101' ],

Extra variables can be put here for your invoker.

        code => <<'CODE'
{
  if (gimage->layers == NULL)
    success = FALSE;
  else
    success = ((gdisp = gdisplay_new (gimage, scale)) != NULL);
}
CODE

The actual invoker code. Since it's a multiline block, we put curly braces
in the beginning.