The previous PDB generation was losing pre-formatting inside
triple-backticked blocks. In particular we were losing indentation
(which was already ugly in C, but even syntactically wrong when
displaying Python code samples). And it was also making us add
double-newlines between every code lines, which was annoying.
This updated code now leaves triple-backticked sections as-is.
Unfortunately I was completely unable to do this by modifying the
existing functions, which were modifying the input arg in-place. So I
made them into functions returning the result. But then there is another
part of code (niceargs()) where changing array contents doesn't work
properly, and worse it seems to corrupt the array somehow (because I
have generation breakage in completely-different pieces of the PDB
generation code). I believe there is some passing-by reference/value
concepts in perl which I don't quite get (they use `&`, `\` and other
symbols and even searching for these, I don't quite understand how to
use them the right way) but I've spent already too much time on this. So
since I've got something working now by having duplicate functions, I'll
let someone else from the future, who knows better perl, re-merge these
functions if they know how.
The 'help' field needs to be single-quoted so that @-values do not look
like perl variables, hence breaking GIR annotations.
Fixing:
> Possible unintended interpolation of @Gimp in string at /home/jehan/dev/src/gimp/pdb/groups/item.pdb line 64.
I double-checked the gi-docgen docs and realized the "Note:" were all on
the same line as previous text. I had forgotten it just removed one
newline. So if I want a new paragraph (double-newline in markdown), I
need 3 newlines in the pdb file.
All the functions working with object's IDs are mostly internal. They
are still made public because they can be useful and are relevant in
specific use cases (i.e. using IDs to reference items in specific
widgets, such as drop-down lists, or when temporarily storing an item as
integer, etc.).
Yet it should be made clear that these usages are the exception rather
than the norm.
...to paths
Follow-up to d0bdbdfd. Changes all
gimp_vectors_* () PDB to gimp_path_* ()
and renames relevant PDB files from
vectors to path.
The next step will be to rename
GimpVectors in libgimp to GimpPath,
removing the last (public) trace of it.
Also:
- renaming gimp_layer_group_new() to gimp_group_layer_new() in order to keep the
same name as in core code (i.e. GimpGroupLayer, not GimpLayerGroup).
- renaming gimp_image_merge_layer_group() to gimp_group_layer_merge()
- new functions: gimp_procedure_add_group_layer_argument(),
gimp_procedure_add_group_layer_aux_argument() and
gimp_procedure_add_group_layer_return_value().
This can be tested, e.g. in Python with these calls:
```py
i = Gimp.get_images()[0]
g = Gimp.GroupLayer.new(i, "hello")
i.insert_layer(g, None, 1)
g2 = Gimp.GroupLayer.new(i, "world")
i.insert_layer(g2, g, 1)
g.merge()
```
This was work started long ago, stored in an old stash which I finally
finish now! :-)
The original reason to skip these was because the new _list_ API were
introspected basically to a similar function signature, except with a
useless return value, at least in pygobject binding where the list size
was also returned.
Though it seems that in fact, only the docstring was wrong. The real
signature was apparently already the same.
See: https://gitlab.gnome.org/GNOME/pygobject/-/issues/352
Therefore since the _get_ naming is more consistent compared to other
existing function, let's re-integrate the _get_ functions for array of
items or images.
This basically reverts commit 15ec254148.
The get() API are sometimes nicer in C code because it's just simpler to
loop through C arrays, but they end up with similar API to the list()
variants for binding, or with a useless size return value (since most
higher level languages have length-aware array types, which is what
GList are transformed into).
So let's use the list() variants as the main ones and skip the get()
variants. I hesitated to rename the list() variants to get() with
`(rename-to)` annotations but since I am unsure if the get() bindings
are absolutely useless, I don't think it's the best idea. Maybe on some
other language usable as GI binding, the get() variant might be
different again and nicer to use. So if we shadowed these by renaming
list() ones, the day we change our mind, we'd have to rename get() ones
too (which would be very confusing), or else break bindings' API. To
avoid this, I just skip the get() ones altogether in bindings but leave
their name available in the bindings.
Fix the dependency by making the stamp an actual (yet empty/no-op)
header file which is included by all generated source file. This way, we
ensure that meson rebuild .o files when the .pdb sources are changed.
This is the second solution proposed by eli-schwartz here:
https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080053413
I cleaned many remaining places where the concept of linked item still
survived.
On loading an XCF file with linked items, we are now going to create a
named sets for the linked items, allowing people to easily select these
back if the relation was still needed.
We don't remove gimp_item_get_linked() yet and in particular, we don't
save stored items into XCF files. This will come in an upcoming change.
Since it appeared with GLib 2.68.0, we could not change this until we
bumped the dependency which has only become possible a few days ago
(since Debian testing is our baseline for dependency bumps). Cf.
previous commit.
As this is a drop-in replacement (just a guint parameter changed to
gsize to avoid integer overflow), search-and-replace with:
> sed -i 's/g_memdup\>/g_memdup2/g' `grep -rIl 'g_memdup\>' *`
… followed by a few manual alignment tweaks when necessary.
This gets rid of the many deprecation warnings which we had lately when
building with a recent GLib version.
In the generated libgimp wrappers, we can't return object arrays
from a call to GIMP_VALUES_DUP_OBJECT_ARRAY() because it returns
a deep copy and adds a reference to all objects, which the caller
would have to unref.
But we want a shallow (transfer container) copy because we don't want
libgimp proxy objects to be refed or unrefed by any user code.
Therefore, add a HACK that simply memdup()s and returns the
GimpObjectArray's array memory, and leaves the contained object
pointers alone.
Turn all ID param specs into object param specs (e.g. GimpParamImageID
becomes GimpParamImage) and convert between IDs and objects in
gimpgpparams.c directly above the the wire protocol, so all of app/,
libgimp/ and plug-ins/ can deal directly with objects down to the
lowest level and not care about IDs.
Use the actual object param specs for procedure arguments and return
values again instead of a plain g_param_spec_object() and bring back
the none_ok parameter.
This implies changing the PDB type checking functions to work on pure
integers instead of IDs (one can't check whether object creation is
possible if performing that check requires the object to already
exist).
For example gimp_foo_is_valid() becomes gimp_foo_id_is_valid() and is
not involved in automatic object creation magic at the protocol
level. Added wrappers which still say gimp_foo_is_valid() and take the
respective objects.
Adapted all code, and it all becomes nicer and less convoluted, even
the generated PDB wrappers in app/ and libgimp/.
This means that images' ownership is not given to caller in particular.
libgimp will now keep a reference of all GimpImage-s it creates and
return this same reference if called again. It also means that you can
now compare images by pointer comparison (as 2 GimpImage objects
representing the same image ID will be equal).
Obviously as a side effect, gimp_image_list() is changed to (transfer
container) as you must only free the container now, not the elements.
Also various other functions creating new images are now (transfer none)
too.
Long-time plug-ins will have to be taken in consideration in a further
step (we currently never free GimpImage for destroyed images in
particular).
I.e.: gimp_image_get_(layers|channels|vectors)(), gimp_image_list() and
gimp_item_get_children().
Instead of returning an array of IDs, these will now return a GList with
the right objects ready to use.
This means that all functions which were returning or taking as
parameter an image id (as gint32) are now taking a GimpImage object
instead.
The PDB is still passing around an id only over the wire. But we create
an object for plug-ins to work on.
This is quite a huge API break, but is probably the best bet for the
future quality. It will make nicer API instrospection (and nicer API in
binding), will fix the issues with pspec on GimpImageID in Python
bindings (which makes the current Python API unusable as soon as we need
to work on images, which is most of our plug-ins!), etc.
Also it will allow to use signals on images, which will be a great asset
when we will finally have bi-directionnal communications (i.e. plug-ins
would be able to connect to image changes, destructions, and whatnot).
So a value array can now we created like this:
array = gimp_value_array_new_from_types (&error_msg,
G_TYPE_STRING, "foo",
G_TYPE_INT, 23,
G_TYPE_NONE);
Change PDB generation to use this, which makes for much nicer code in
the libgimp wrappers, and only set arrays separately instead of all
values.
Also generate comments like "Must be freed with g_free()" for all
return values instead of manually and inconsistently having them on
some return values only.
This reverts commit 833666d462.
The _pdb files are an implementation detail and we do not want
separate doc sections for them, the conflicts need so be resolved in
another way.
Otherwise we get a few duplicate sections since some of the non-PDB
files are named similarly.
Fix this GObject introspection warning and other similar warnings:
> libgimp/gimp_pdb.c:28: Warning: Gimp: multiple comment blocks
> documenting 'SECTION:gimp:' identifier (already seen at gimp.c:129).
All foo_pdb.c functions in libgimp regenerated. I have reviewed this a
dozen times, but please have a look, there might well be glitches and
our public API is sortof important...
Add property "color-tag" of type enum GimpColorTag to GimpItem so all
layers, channels and paths can be tagged with a color.
For interoperability, use the color list from Krita which is a
superset of Photoshop's colors.
Features a "Color Tag" submenu in the layers, channels and paths
menus, a row of color radio buttons in the properties dialogs,
undo and PDB API.
As a side effect, some common code is now factores out into
items-actions.[ch] and items-commands.[ch] which adds visible, linked
and lock actions for layers and channels.
In e61b1f76 things were changed to return string arrays that can be
freed with g_strfreev(), but that returned a one-element array
containing a NULL pointer for zero-length arrays. Fix the code
to return NULL again for zero-length arrays. See bug #751584.
Jehan