When clicking on the selection mask (in the dockable view) or when
dropping a color on this same view, we can now select by color based on
the selected layer composition (not only one single layer, nor the whole
image as sample merged, but also a specific list of composited layers).
gimp_channel_select_by_color() is made multi-drawable aware as a
consequence of this.
When several layers are selected, each layer will merge down with the
layer below it. This is similar to running Merge Down several times, one
for each selected layer.
This implied a lot of other core changes, which also pushed me into
improving some of the edit actions and PDB calls to be multi-layer aware
in the same time.
Note that it is still work-in-progress, but I just had to commit
something in an acceptable intermediate state otherwise I was just going
crazy.
In particular now the various transform tools are multi-layer aware and
work simultaneously on all selected layers (and the linked layers if any
of the selected layers is linked too). Both preview and final transform
processing works.
In the limitations, preview doesn't work well (only one layer in the
preview) when there is a selection (though the actual transform works).
Also I am left to wonder how we should process this case of canvas
selection+transform on multi-layers. Indeed currently I am just creating
a floating selection (like we used to for the selection+transform case)
containing a transform result of the composited version of all selected
layers. This is a possible expected result, but another could be to get
several transformed layers (without composition). But then should the
"Floating Selection" concept allow for multiple Floating Selections?
Sooo many questions left to answer.
The PDB creates the array of drawables as a `const GimpItem *` and the
compiler does not like when we drop the const qualifier. So force this
const dropping with explicit type casting.
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.
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).
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.
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).
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.
... (used to add one automatically)
In GimpFilterTool and gimp_drawable_apply_operation(), use
gimp_drawable_filter_set_add_alpha() to add an alpha channel when
applying an operation that specifies "needs-alpha" to a drawable
that can have alpha.
Don't disable gegl:color-to-alpha (which has "needs-alpha") when
the drawable doesn't have an alpha channel, if one can be added.
In plug_in_compat.pdb, when wrapping an op node inside a graph, set
the op node as the graph node's underlying operation. This allows
gimp_gegl_apply_operation() to perform certain optimizations.
In plug_in_compat.pdb, don't add child nodes to nodes containing an
op, since this turns them into graphs and discards the op.
Instead, add a new wrap_in_graph() helper function, which takes a
node op and wraps it in a simple "input -> op -> output" graph.
Use the graph as the container for child nodes, and as the node
passed to gimp_drawable_apply_operation(). (This is similar to
what we used to do before commit
afdd573136, except that we now pass
the parent node to gimp_drawable_apply_operation(), instead of the
op node).
and in an attack of madness, changes almost all file plug-in
code to use GFile instead of filenames, which means passing
the GFile down to the bottom and get its filename at the very
end where it's actually needed.
It's an ancient concept from ancient times when we didn't have URIs
and only filenames (not to speak of GFile), and actually even from
before the ancient time before that ancient time when we first had
ones and zeros, and only had zeros.
They are simply setting properties on GimpPlugInProcedures, just like
the other functions in gimpplugin-proc.[ch], so there is no reason to
have them elsewhere and with worse checks and error messages.
Jehan