gimp/pdb
Jehan ddcaa99264 app, libgimp*, pdb, plug-ins: review and enhance MR !1549.
- Fix annotations for gimp_export_options_get_image() to make it
  actually introspectable with the GimpImage being both input and
  output. Even though the logic doesn't change much (the input image may
  be overriden or not), it doesn't matter for introspection because
  images are handled centrally by libgimp and therefore must not be
  freed. Actually deleting the image from the central list of images
  though remains a manual action depending on code logic, not some
  automatic action to be handled by binding engines.
- Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image()
  because ignoring the returned value is rarely a good idea (as you
  usually want to delete the image).
- Remove gimp_export_options_new(): we don't need this constructor
  because at this point, the best is to tell plug-in developers to just
  pass NULL everywhere. This leaves us free to create a more useful
  default constructor if needed, in the future. Main description for
  GimpExportOptions has also been updated to say this.
- Add a data_destroy callback for the user data passed in
  gimp_export_procedure_set_capabilities().
- Fixing annotations of 'export_options' object from pdb/pdb.pl: input
  args would actually be (nullable) and would not transfer ownership
  (calling code must still free the object). Return value's ownership on
  the other hand is fully transfered.
- Add C and Python unit testing for GimpExportOptions and
  gimp_export_options_get_image() in particular.
- Fix or improve various details.

Note that I have also considered for a long time changing the signature
of gimp_export_options_get_image() to return a boolean indicating
whether `image` had been replaced (hence needed deletion) or not. This
also meant getting rid of the GimpExportReturn enum. Right now it would
work because there are no third case, but I was considering the future
possibility that for instance we got some impossible conversion for some
future capability. I'm not sure it would ever happen; and for sure, this
is not desirable because it implies an export failure a bit late in the
workflow. But just in case, let's keep the enum return value. It does
not even make the using code that much more complicated (well just a
value comparison instead of a simple boolean test).
2024-08-18 22:46:47 +02:00
..
groups app, libgimp*, pdb, plug-ins: review and enhance MR !1549. 2024-08-18 22:46:47 +02:00
README pdb: update README with new path. 2018-01-11 05:24:59 +01:00
README_NEW_PDB_PROC pdb, libgimpbase: Rename GIMP_VECTORS_STROKE_TYPE... 2024-07-19 15:07:43 +00:00
app.pl core, pdb, plug-ins: Create GimpExportOptions class 2024-08-18 22:03:14 +02:00
enumcode.pl libgimp, pdb: Fix enums_get_type_names annotations 2023-05-22 01:19:17 +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, libgimp: allow to use external GType-registered enums in the PDB 2018-03-17 20:31:48 +01:00
enums.pl Issue #8900 and #9923: reimplementing GimpUnit as a proper class. 2024-08-02 10:46:38 +02:00
groups.pl pdb, libgimp: Rename libgimp GimpVectors vectors API... 2024-07-08 23:39:51 +00:00
lib.pl pdb: getting rid of some warnings in a perl script. 2023-12-08 20:58:59 +09:00
meson-enumcode.sh libgimp, pdb: (meson) fix building of libgimp/gimpenums.h inside the source tree. 2023-10-01 21:02:33 +02:00
meson-enumgen.sh libgimp, pdb: (meson) fix building of libgimp/gimpenums.h inside the source tree. 2023-10-01 21:02:33 +02:00
meson-pdbgen.sh pdb: meson-pdbgen.sh should return the return value of pdbgen.pl. 2023-02-14 15:36:19 +01:00
meson.build pdb, libgimp: Rename libgimp GimpVectors vectors API... 2024-07-08 23:39:51 +00:00
pdb.pl app, libgimp*, pdb, plug-ins: review and enhance MR !1549. 2024-08-18 22:46:47 +02:00
pdbgen.pl Issue #5946: skip gimp_*get_*() API from GObject Introspection. 2022-06-27 21:20:06 +02:00
stddefs.pdb 2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush 2023-01-14 12:58:05 +00:00
util.pl Change the license URL from http://www.gnu.org/licenses/ to https:// 2018-07-11 23:29:46 +02:00

README

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.