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.
Now that we have implementations for select_items everywhere and that
all the code is only wired to call or handle select_items, the single
item variant select_item is of no use anymore. Let's make a big cleanup.
… the container.
There was this weird case which we somehow could only reproduce on
Aryeom's computer/build, not mine, with the same code and reproduction
steps (reproducible at will on her build only). Basically when drag'n
dropping a duplicated layer inside a collapsed layer group, the
row-expanded handler would try to select the moved layer before it is
actually inserted. This would end up into crash-happy code.
I'm still unsure of why the order of operation is different here, but
anyway what is for sure is that the `inserting_item` boolean flag was
not protecting much. It's not like it's an actual mutex and anyway this
is not multi-threaded code either so this flag was mostly useless (which
is why we were crashing). Instead let's actually look if the item is in
the container or not.
The bin window coordinates must be converted to the widget coordinates.
This was not a problem before, but now with the column header, if I
don't do this, the position is wrong.
Similarly fix the lock popover position.
The header shows a lock icon, making the column more discoverable, as
well as where to click.
Also the title for the item column will now be used for the
multi-selection label (counting items) instead of using
GimpItemTreeView's options box.
Finally use the new gimp-multi-lock icon to show multiple locks.
This makes for much nicer and usable item tree.
… the selected items only.
This is the exact same algorithm as Shift-click, except that Shift-click
switch exclusivity within the whole level of items. Alt-click does the
same but only within selected items in the list.
Similar to exclusive visibility switch on layers, now for locks too, if
one wants to lock all layers within a same level for instance by
Shift-clicking the lock icon.
Also once again I factorized the exclusive switching code to ensure it
will always works the same for all similar features (visibility and all
locks).
First of all, let's use gtk_widget_show|hide() instead of
gtk_popover_popup|down() because these GtkPopover API sometimes "block"
when clicking very fast on the item list, sometimes up to 2 or 3 seconds
(at least it feels like seconds, I haven't actually timed it!). I'm sure
the ones who developed it thought it was nice to have slow popping
dialogs, but when working fast, this can only be frustrating).
The second responsiveness change is that when clicking out of useful
lock popover area, it should not only close, but the event should be
passed onto the item tree view when relevant. This allows for instance
to directly click on an eye cell to change a layer visibility without
having to click twice.
Use this for the alpha lock brought by GimpLayerTreeView.
Also use the new gimp_widget_blink_rect() to only blink the appropriate
cell when a lock is preventing you from doing something.
… and drop the link cell (the lock cell takes the space).
This is an experiment with the following logics:
* I am getting rid on the linked item logics, so the icon cell
disappears anyway.
* The lock buttons are not so visible above the Layers dockable and so
many have I seen people frustrated of not being able to do some action
until they realize they locked something in the layer (even sometimes
advanced users).
The icon next to the eye is much more visible. Also I will now display
different icons depending on the type of locks. If a single lock is in
effect, I show the corresponding icon. If 2 or more locks are in
effect, I show a generic lock icon.
* With multi-selection of items in particular, this top lock row was a
lot more weird and could show inconsistent state (some of the
selection is locked, other is not). Now the per-row lock icon allows a
much nicer granularity.
Sometimes one may want to lock visibility of a given layer. This is very
useful in particular when shift-clicking a layer visibility. In this
case, it won't be included in the list of layer to update. This can be
used for instance if you want some layers always visible (or always
hidden) while setting exclusive visibility of some other layers only.
Rather than trying to fix up our own heuristics using a
`GtkMenuPositionFunc`, use whatever GTK provides to position given a
specific rectangle, which also has the benefit of nicely integrating
with GDK backends such as Wayland. Another advantage is that we can use
GdkGravity to center the popup.
Since GTK 3, GtkWidget also gained a "popup-menu" signal, which we
can/should use instead of rolling our own context signals.
… Selection.
I first wanted to switch the modifiers to Alt+shift, Alt+Ctrl clicks and
even implemented the changes, but realized the existing "Alpha to
selection" on Alt thumbnail clicks already mapped these for
Add/Remove/Intersect Alpha to Selection (though I broke this with commit
14b4c08881 but re-allows properly with exact modifier recognition in
order not to catch other types of combinations).
In the end, I see no other solutions than actually removing the mask
add/remove modifiers (#if-ed 0 for now, we'll see) in favor of the most
ancient feature.
When Alt-clicking on an item thumbnail (for instance a layer thumbnail),
we can trigger an "Alpha to Selection" action on the clicked item. Yet
the check was not accurate and would work on Alt+any modifier(s)+click.
Let's catch exactly Alt-click only in order to allow for more actions on
other combinations.
… multi-selected items.
The idea is that with multi-selection now enabled, you may always lose
track and forget you have several items/layers selected. This is
especially true when you have a lot of layers (say you selected one at
the top of the list, another at the bottom; without scrolling, you may
only see one of them). And this can become bad when doing some
destructive action which is allowed on several layers at once (say
deleting several layers while you thought you were deleting only one!).
I got the idea from Thunderbird GUI which also displays the number of
selected conversations in the email list. Same as in Thunderbird, I also
wanted to theme the label similarly to a selected item in the item list
below. This was hard because there is no way to reference the parent
theme colors from within GIMP one. Instead I made so that the label is
always shown as a fully selected text (which is a bit ugly semantically,
but I could not find better). Why I wanted this styling is to give *a
bit* of focus to this info so that it is not too invisible. Otherwise
purpose is defeated. Yet this label is still more subtle than
Thunderbird one (don't want to take all attention toward it). Hopefully
this got the right in-between style.
In the middle of multi-item insertion, you don't want to run
gimp_container_view_select_items() as was being done in
gimp_item_tree_view_insert_item_after(). As it turns out, this is the
only implementation for this virtual function, and it doesn't need to be
run on the specific inserted viewable, just make it a call to run when
all insertions are done.
Though it's not finished yet, I am changing "active layer" into
"selected layers" logics. Probably the "active layer" concept will be
back eventually (i.e. even in a multi-selection a specific layer could
be said "active", highlighted in the list a bit differently, hence one
could edit this specific layer only). But for simplicity, for now, it's
better to first get rid of it, otherwise it's just messy.
This whole drag'n drop code is quite overwhelming, I'm pretty sure this
commit introduced various bugs, and there are already several areas of
improvements I noticed. But at some point, I need to split at a not-too
broken code state or I'll just make things worse.
I wanted to enable it in the end, but it makes my work tree messy. Just
commit this now. Multi-selection basically works but there are still a
lot of broken features which are to be taken care of one by one.
Only enabled for layer tree so far.
Properly pass the multi-selection information through the container
classes. Previous implementation was incomplete (most code paths with
multiple item selected were just ignored) and data was passed through
the "select-item" signal with the GimpViewable to NULL and the data to a
list of items (instead of being a GtkTreeIter otherwise). Having a
pointer data which changes meaning in the same function/class is not the
best idea. So instead "select-items" will have 2 list as parameters: a
list of items and a list of GtkTreePath to be used similarly and with
less ambiguity.
* Don't generate our own marshallers if they are available in GLib
already
* Don't set the c_marshaller parameter in `g_signal_new()` if it's a
default marshaller provided by GLib. See commit message of commit
39e4aa3c57 on why this is the case.
Step one: get rid of all those deprecation warnings that make
it hard to see any other warnings:
- add a lot of dummy API to GimpAction, GimpActionGroup, GimpUIManager
etc. which simply forwards to the deprecated GTK functions, they
will all go away again later
- rename GimpAction to GimpActionImpl
- add interface GimpAction that is implemented by all action classes,
creates a common interface and allows to remove some duplicated
logic from GimpToggleAction and GimpRadioAction, and at the same
time adds more features
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
Add gimp_item_get_merged_color_tag(), which returns the color tag
of the nearest ancestor (including the current item) that has a
color tag other than NONE. Use this function in GimpItemTreeView,
instead of gimp_item_get_color_tag(), to set the cell color of
items, so that item's with a NONE color tag inherit the color of
their parent. Add a boolean "inherited" parameter to
gimp_get_color_tag_color(), which indicates if the color tag is the
item's actual color tag, or an inherited color tag, and modify the
returned color accordingly, so that inherited colors are less
saturated/lighter than non-inherited ones.
Try to sort all GIMP_ICON_* defines into FDO categories like in
https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html
Add defines for all icons we override, rename some icons to their FDO
standard names, and mark the ones we duplicate with a comment so we
don't forget to rename those to standard names in 3.0.
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.
Apply and heavily modify patch from remyDev which adds "lock position"
to GimpItem, similar to "lock content". Lock position disables all
sorts of translation and transform, from the GUI and the PDB.
Cleaned up some aspects of the lock content code as well because a
second instance of similar code always shows what went wrong the first
time.
Jehan