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.
Basically if you enabled OpenCL or any of the experimental tools, it
will show the Playground in Preferences. Otherwise, say you enabled some
experimental feature months ago (e.g. with the CLI option) and you now
experience crashes or whatnot. And you forgot how to change it, and only
remembered that there was something in Preferences. It would make you
crazy to not find the tab again to disable the option.
This is even more important as OpenCL is moving from a normal option to
a playground option. So you might not even have ever seen the Playground
tab in Preferences and would not know how to disable OpenCL after you
enabled it originally in "System Resources" tab.
So now Playground is visible with any of these 3 conditions:
* If you use an unstable version.
* If you run GIMP with --show-playground option.
* If you previously enabled one of the playground options.
If the next visible layer below a selected layer is itself selected, we
want to create bigger merge list with all 3 layers merged at once (or
even more if the next-next is also selected, and so on).
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 seems to have been broken since much longer, but it only made a
problem with recent changes. Since we were duplicating layer groups and
contents layers at once, the current code could not keep layer selection
other than at root level in a duplicated image.
Use the layer paths to make sure we select exactly the right copied
layers, since the path should not change in a fully duplicated image.
Fix horizontal downscaling of brush mipmap levels with odd width.
We'd previously fail to skip the last pixel of each input row,
which isn't included in the output when the width is odd, causing
subsequent output rows to be shifted to the right.
In GimpDrawableFilter and GimpFilterTool, use an absolute offset
for the split-preview guide position, instead of storing it as a
fraction of the drawable's width/height. The latter could
introduce rounding error, which would result in wrong coordinates
when converted back to an absolute offset.
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.
This function returns a new list of items from an input list. The output
list will optionally contains linked items if any of the input item is
linked so we don't have to rewrite the same duplicated code for every
feature where item links matter.
Moreover it also filters descendants if any of the input items is an
item group, hence avoiding to apply a transformation twice to a
descendant item.
Use this new function already in 2 places, hence skimming quite a bit of
redundant code.
This can be used in various places where we want to check whether a
previously saved list of drawables is still the same list of selected
drawables. It used to be easily done with an equality test with a single
active drawable, but not anymore with a list of selected drawables.
In GimpImageProxy, implement GimpColorManaged by forwarding the
functions to the underlying GimpImage, and forwarding the signals
in the other direction. This fixes color-managed view in the
Navigation dockable.
When converting an image to indexed mode, zero-out transparent
pixels instead of leaving junk in their indices, which might well
be out of range of the palette.
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.
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.
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.
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).
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).
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.
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.
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.
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".
Instead of a single active item, we now have a list of selected items. I
keep the concept of "active" item (for now at least) when there is one
and only one item selected.
Also note that when inserting an item into the active parent's
container, it now requires all selected items to have the same hierarchy
(same parent). Same when adding on top of the selected items (in which
case, it means on top of the highest one).
From commit 529aa743:
> `g_object_notify()` actually takes a global lock to look up the
> property by its name, which means there is a performance hit (albeit
> tiny) every time this function is called. For this reason, always try
> to use `g_object_notify_by_pspec()` instead.
While just _loading_ GIMP on my machine (ie during the splash screen)
`g_object_notify (curve, );` got called more than 6000 times already, so
it's not an unused path.
Note that it's also less easy to make an accidental typo when using
`g_object_notify_by_pspec()`, as the compiler will complain about the
enum value being incorrect.
There is no non-hackish way of fixing this without adding a new
"use-opacity-paint-mode" property to GimpToolPreset and a new toggle
in GimpToolPresetEditor. Restoring opacity and paint mode can now be
controlled explicitly, and defaults to TRUE.
Jehan