There is really nothing specific to the core application, it is quite a
generic widget, so it would be nice for plug-ins to be able to use this
widget.
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.
