As I review and tweak various aspects of GIMP UI, I also write down
specifications for these subparts. Here is one for the locks behaviors.
We worked on these specifications with Aryeom and tried to make the most
useful and also somehow obvious logics for these locks, in particular
the cases when applied to layer groups which can have wider ranges of
meaning (on leaf items, it is much simpler). The various previous
commits are implemented based on these specifications.
XCF 17 includes the new visibility locks and the ability to add position
and alpha locks on layer groups.
I am going to push the various commits implementing these different
features together which is why we gather them as a single XCF version.
We want it to work whatever the level in the item tree. We only care
about whether the items are selected or not.
Also fixing the AppStream release tag for the description of this
feature.
Unlike other locks, visibility lock is less useful for locking a whole
hierarchy of item and their children. On the other hand, being able to
lock a group visibility while editing the children visibility is quite
useful.
It can be argued that layer groups can't be painted on, and that's
probably the original reason, but it's really just the same as "Lock
pixels". It is interesting to be able to lock alpha channels on a layer
group to simply lock all its contents alpha channels.
Since we are now allowed to move groups (which is the same thing as
multi-selecting all its children and moving them), it makes no sense
that this lock is disabled.
This works the same way as "Lock pixels" in that a locked grouped also
forbid moving children. And there was already some logics so that you
can't move a layer group if one of it's children is locked. So this lock
really works both ways and is a bit special.
Finally I cleaned up a bit the multi-layer selection logics and
messaging, as well as which lock to blink (similar to the previous
commit) for the "Lock position" case.
In particular, if painting on a layer whose parent's pixels are locked,
we were blinking an empty lock spot, which is confusing. Now
gimp_item_is_content_locked() will also return the proper item (when
relevant, i.e. when returning TRUE) which is locked. It may or may not
the same item as passed in (it may also be a parent item in particular).
Fixes:
> make[3]: *** No rule to make target '64/dialog-question.png', needed
> by 'gimp-core-pixbufs.gresource.xml'. Stop.
It looks like a bug in autotools on Windows because there is no reason
why it would fail. The missing PNG should be caught by the '64/%.png'
rule. Anyway after testing, it fixes the gimp-win(32|64)-native CI jobs.
As Massimo notes, the issue is not about the callback being broken in
bindings, but simply that bindings fail to handle random data without an
associated size. So let's just add the size. I confirmed testing API in
the Python binding that it now works fine.
See discussion in !572, #7840 and #7690. Note that this was reported on
macOS where the consequences were pretty dire, but it actually also
happens on other platforms, at least on Linux too (as confirmed in X11
with the GTK Inspector set to show graphics updates; on Wayland this
debug option doesn't work, but I assume it is the same).
I am not perfectly happy with this change either, because it is based on
part of the API which has various deprecated parts (hence doesn't exist
anymore on the main dev tree, i.e. it might have to be reviewed in GTK4;
of course, it's unsure, maybe the whole resize propagation to parent
containers is just better handled there and the problem won't exist
anymore).
In any case, it is cleaner than the proposition for this part of the
problem in !572 which is problematic (patching GtkLabel with a new API
which won't trigger resize even when actually needed, hence which likely
won't ever get accepted upstream because it's not right).
Let's sync with the proposal in !571 after discussing with Jacob. The
shorter naming is fine and the '-info' suffix feels a bit redundant
anyway. Also since this arg never even existed in GIMP 2.10 (until !571
which is soon to be merged), there is really not even a historical
reason.
NULL is not a proper value for GStrv yet we cannot escape it in the PDB
since we generate default values for non-passed arguments (especially in
interactive case where most procedure arguments aren't set). And for
such boxed type, it will be NULL.
So when we see a NULL GStrv parameter, let's not ignore it (which will
just crash the plug-in). Simply transform it to a GStrv of size 0.
GLib has a specific type of NULL-terminated string arrays:
`G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`.
By using this type, we can avoid having a `GimpStringArray` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GStrv`, we allow other languages to pass on string lists as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with string arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
While we do have quite a few gimp_pdb_run_procedure*() functions now, I
always felt that one based on a config file was missing, even more as we
are getting further and further into using config objects in plug-ins.
In C, the gimp_pdb_run_procedure() function is without a doubt the
easiest one. But such variable arg functions are not available on
bindings, and having to deal with GValue and GimpValueArray is a real
pain.
Also using a config file has the very great advantage that we don't need
to care about order. For instance, if I need to set the 10th argument of
a PDB call (and leave the rest to default values), I don't have to set
all 9 previous arguments. I can set only this one if I want. This
advantage is useful also for C code by the way.
For the record, here is how you could load then export an image with the
"file-png-*" PDB procedures in Python:
> c = Gimp.get_pdb().lookup_procedure('file-png-load').create_config()
> c.set_property('file', Gio.file_new_for_path('/path/sample.png'))
> r = Gimp.get_pdb().run_procedure_config('file-png-load', c)
> d = Gimp.Display.new(r.index(1)) # Give it a display to work on it.
Now exporting:
> img = r.index(1)
> c = Gimp.get_pdb().lookup_procedure('file-png-save').create_config()
> c.set_property('image', img)
> c.set_property('file', Gio.file_new_for_path('/path/exported.png'))
> layers = img.get_layers()
> c.set_property('drawables', Gimp.ObjectArray.new(Gimp.Drawable, layers, False))
> c.set_property('num-drawables', len(layers))
> r = Gimp.get_pdb().run_procedure_config('file-png-save', c)
… object arrays.
We were not supporting duplicating object pspec for no good reason. Well
maybe the reason was that libgimpconfig does not see these types which
are in libgimp. But then the trick is to compare by name.
As for object array, they are present as subtypes of GimpArray specs.
Yet most GimpParamSpec*Array-s are subclass of GimpParamSpecArray but
GimpParamSpecObjectArray are their own GParamSpecBoxed subclass (same as
the Gimp*Array-s are just typedef-s of GimpArray but GimpObjectArray is
its own boxed type).
So I had to move the object array test as its own case to fix support.
Finally do not ignore anymore any type in gimp_config_class_init(). When
we create a GimpConfig, we want to know when a type is not implemented
as parameter (and if it's a well known type, we need to implement it).
Anders Jonsson