I created a new function gimp_channel_combine_items() which combines a
list of items with a channel. The list of items is first combined
together as an union set, then only combined with the channel with the
desired operation (this is important for operations such as intersect
which was broken in my previous commit because all items would be
intersected with each other and the selection, whereas we actually want
the union of all items to be intersected with the selection). This new
function is now used for "Alpha to Selection".
Also similarly to copy or color-pick on multi-layers, alpha to selection
will now use the composited result of the multi-layers as visible. In
particular it means that opacity, modes and visible properties on the
layers are taken into account. Alpha to selection on a single layer
though still works as previously, only taking the non-composited layer
data into account.
I am actually struggling if alpha to selection on uncomposited layers
(just an union on alpha to selection result for each layer) would not
make sense to on some workflows. To be experimented.
Finally it is to be noted that this function should also work on
channels and vectors (both single or multiple; and of course in such
cases, compositing does not matter) though I haven't tested yet. It
could even work with a source mix of layers, channels and vectors,
though our GUI does not allow such action currently.
Wherever we store arbitrary-format colors in an opaque buffer, use
double for the buffer, instead of char, so that it has a strict-
enough alignment to handle all our used pixel formats.
It means forbidding gradient tool to work (with appropriate error
message) on multiple selection. Applying gradient on several layers at
once is not supported at this point.
This fixes:
> GEGL-WARNING: (../../src/gegl/gegl/buffer/gegl-tile.c:127):gegl_tile_dup: runtime check failed: (! src->damage)
Which happened when a GEGL operation was running and you canceled it in
the middle, say with the ESC key (easy to reproduce with long operations
such as "Color to Gray"). In such case, obviously don't try to copy the
unfinished operation result into the dest buffer.
This fixes bugs introduced in commit a7c59277fb where I obviously didn't
properly checked all the places where gimp_selection_float() was used
after its parameters changed.
Multi-drawable selection for text tool only matters for positionning the
newly created text layer, if relevant. If a single layer is selected, it
will be same as before.
With multiple selection, the new layer just ends up to the top in case
of layers from different containers.
Color picking on a single layer still works as it used to. On multiple
layer, it will now pick on the composited color, similarly to sample
merged if only selected layers were made visible.
The PDB/libgimp function gimp_image_pick_color() is also updated to work
on multiple drawables too, giving the same ability to plug-ins (the only
call to this function in core plug-ins have been updated).
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).
Jehan