When creating a palette out of an image without checking "Sample
Merged", it will now extract the colors out of each individual selected
layers separately. This allows to create palettes even out of all layers
of an image but still considering these individually.
I am currently unsure of this one. Since GimpCanvasLayerBoundary is a
GimpCanvasRectangle, it now shows the minimum rectangular boundary
containing all selected layers.
Should we instead show all individual layers boundary? I didn't choose
this because it would make the whole canvas much more messy, and also I
figure that layer boundaries are mostly used to get an idea of your
current working space extent, for instance if we were to resize the
canvas. Matter to discuss, I guess.
Multi selection actually only really matter when "Merge within active
groups only" option is checked, in which case we are able to merge
layers within several layer groups simultaneously, and end up with
multi-selected merged layers.
Also not sure why both layers-merge-layers and image-merge-layers exist,
as they are exactly the same (exact same callback called when
activated).
When several layers are selected, select their render, similar to how
"edit-copy-visible" would have copied an image with only these layers
made visible.
Also apply the same logics to PDB function gimp_edit_copy() which can
now be used on several drawables at once.
Similarly to shift-click on visibility or link toggles, shift-click on
expanders allow to expand/collapse all layer groups at a given level,
but the one initially clicked.
- Don't trigger selection when toggling visibility/links.
- Fix some weird selection jump when clicking while editing a layer
title.
- Return FALSE in GDK_BUTTON_RELEASE so that viewable larger preview
popup gets closed on mouse release.
These actions raise a GimpViewableDialog. For this to work, I made this
widget work with a list of GimpViewable, not a single viewable anymore
(so maybe the widget class name should change?).
When this list contains only a single GimpViewable, it will display
exactly like before, with a viewable preview. With several viewables,
the preview won't show.
This allows to add masks to all selected layers at once, with the same
basic options for all masks, as set in the dialog.
Both with the various action layers-lock-alpha, layers-opacity-* and
layers-mode-*, as well as through the layer tree view GUI (alpha lock
icon, opacity slider and layer mode combo box).
Not fully happy of the action sensitivity tests as they check for
content-lock, layer groups and such, but independently. So we could have
a case with 2 layers selected: a group + a content-locked layer. Yet the
layers-mask-apply action would be sensitive.
But instead of make more tests, I am nearly wondering if we should not
make action sensitivity more lax as the actual action will make the
tests anyway and just do nothing.
… 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.
This commit just changes our saving API (i.e. the GimpSaveProcedure
class) to take an array of drawables as argument instead of a single
drawable.
It actually doesn't matter much for exporting as the whole API seems
more or less bogus there and all formats plug-ins mostly care only
whether they will merge/flatten all visible layers (the selected ones
don't really matter) or if the format supports layers of some sort. It
may be worth later strengthening a bit this whole logics, and maybe
allow partial exports for instance.
As for saving, it was not even looking at the passed GimpDrawable either
and was simply re-querying the active layer anyway.
Note that I don't implement the multi-selection saving in XCF yet in
this commit. I only updated the API. The reason is that the current
commit won't be backportable to gimp-2-10 because it is an API break. On
the other hand, the code to save multi-selection can still be backported
even though the save() API will only pass a single drawable (as I said
anyway, this argument was mostly bogus until now, hence it doesn't
matter much for 2.10 logics).
… with gimp_pdb_execute_procedure_by_name().
While using gimp_pdb_execute_procedure_by_name_args(), you would create
the GValue-s manually, gimp_pdb_execute_procedure_by_name() is supposed
to create them for us from common C/glib types.
C arrays in particular don't have length information and we can't just
G_VALUE_COLLECT() them (it ends up in broken array with length 0). By
convention, the array length will be the previous parameter. So let's
use this information and create the GValue with gimp_value_set_*_array()
instead.
It is meant to replace gimp_image_get_active_drawable() in the end.
Note that I am not fully sure yet what we should do with multiple layers
selected, when some of them have a mask which is being edited.
This got broken by some actions now performed on GDK_BUTTON_RELEASE,
i.e. after GDK_2BUTTON_PRESS. Let's shortcut these actions on specific
case when we edit a cell.
After much thought, tests and discussions with Aryeom, we decided adding
back an active item concept additionally to the selected items ones is a
bad idea as it makes only usage unecessarily complex.
We will just have selected layers. Some kind of operations will work
when more than one item (layers, channels, vectors) are selected while
others will require exacty one item.
In particular, let's replace instances of gimp_image_(s|g)et_active_*()
by corresponding gimp_image_(s|g)et_selected_*(). Also replace single
item in various undo classes by GList of items.
Also "active-*-changed" GimpImage signals are no more, fully replaced by
"selected-*s-changed".
This is still work-in-progress.
This was already implemented for the new button which had its own drag'n
drop handler, and now also for other buttons (in particular the delete
button which is multi-item aware).
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.
For single drawable drag, we still display the name of this only layer.
Also apply some basic markups, showing the drawable count as italic
subscript in parentheses to differentiate it from a drawable name.
I was changing selection only on button release because we don't know if
the initial button press is not going to actually become a drag'n drop
operation. Nevertheless it had a counter-intuitive effect when
multi-selecting some layers then trying to drag another (non-selected)
layer.
To fix this, I actually change the selection on *press* event but only
if the pressed item is currently non-selected.
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.
Right now, the active item concept is just a weird (and broken)
subconcept of "selected-items". Do not notify for this as it breaks
multi-selection. This can be re-notified later when we will make a
proper concept which won't mean "selection of 1 item".
Basically the single click selection must happen on mouse button
release, not initial press, otherwise it would cancel your multiple
selection when you were actually about to drag the items.
As for contextual menu, it should trigger a selection only when the
clicked item is not in the current multiple selection.
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.
Jehan