Similar logics as Fuzzy Select (see my previous commit), which is that
if multiple layers are selected (and sample merged unchecked), it
selects as though through a composited image containing only the
selected layers.
When several layers are selected, and using the Fuzzy select tool
without sample merged (with sample merged, nothing changes, it just uses
the whole image), the selection will be based off a composited render of
the image with only selected layers.
This is equivalent to only making selected layers visible, running fuzzy
select with sample merged, then making other layers visible again.
When dropping a color, we fill all the selected layers with this color.
When dropping a buffer, multi-layer is same as no layers selected (i.e.
we paste once as a new layer, not multiple times).
Logics stay the same except I replace gimp_image_get_active_drawable()
by gimp_image_get_selected_drawables() to show I looked at this code.
Basically it doesn't look like we can really handle multiple layer
selected here, unless we want overly-long window titles.
This got *again* broken because of some obviously impossible code path
(a same variable tested against 2 different values!). Anyway I tested
again and it seems that all possible interactions in the item tree views
are now correctly working though the whole button press code is a very
complicated mess of possible variations and events.
Making these actions multi-layer aware here means checking only exactly
1 layer is selected as these actions have GUI which shows dimensions and
preview (for the layer dimension action, i.e. layers-resize).
The `info line` in particular was given by Ell and will make trace
handling a lot easier as it means we may not have to ask for traces with
debug symbols or gdb with Flatpak. We can indeed get these infos back
ourselves since we are guaranted to use the exact same binaries.
This together with the change in verbose version output I did 2 weeks
ago (commit bc5f6371e9), allowing us to check the exact Flatpak hash
commit used by a reporter, Flatpak debugging should be a lot easier with
just the simpler stack trace format.
The call to "gimp-xcf-save" was not updated to the new API using a
drawable array and a GFile.
Also for the drawable array, do not actually create it as anyway this is
a dummy argument (so far XCF saving does not even look at this argument
and just re-check the selected drawables).
This parameter is not even used because we check again the selected
drawables during the save code. Allowing to set to 0 is simpler, and
also it will allow to not have to allocate an object array for layers
when we want to avoid memory management (during crash handling).
… argument validation.
I had a case where argument validation was failing on range and no error
was propagated (during a crash handling). Let's not leave these errors
totally silent as it makes such usually easy issues harder to debug. In
the specific case of no GError passed, just print the error to stderr.
Add a new performance-log-progressive-coalesce.py tool, which
coalesces partial address maps in progressive performacne logs into
a single global address map, suitable for processing by the rest of
the tools.
Use the new tool as part of the pipeline in performance-log-viewer.
Add a new performance-log-close-tags.py tool, which closes unclosed
tags in incomplete performance logs, allowing the rest of the
perofmance-log tools to process them. This is necessary for
unfinished progressive logs.
Use the new tool as part of the pipeline in performance-log-viewer.
Add an option to record progressive performance logs. Progressive
logs contain complete information after each recorded sample, by
writing partial address maps at each sample, containing all new
addresses introduced by the sample. Furthermore, when recording a
progressive log, the output stream is flushed after each sample.
This allows recording complete logs even in cases where they can't
be properly terminated, such as when GIMP crashes or freezes in the
middle of the log.
Progressive logs are disabled by default, since they potentially
increase the sampling cost. They can be enabled through a toggle
in the log file-dialog, or through the
GIMP_PERFORMANCE_LOG_PROGRESSIVE environment varaible.
When recording a performance log, allow setting the log parametrs
through the file dialog. Currently, this includes the sample
frequency, and the option to include backtraces.
These options are still controllable through the
GIMP_PERFORMANCE_LOG_SAMPLE_FREQUENCY and
GIMP_PERFORMANCE_LOG_BACKTRACE environment variables. When set,
the variables override the values entered through the UI.
This fixes default constraint values when multiple layers are selected.
In particular fixed aspect ratio defaults in Crop or Rectangle Select
tools, in layer mode, when several layers are selected, the default
aspect ratio is the layer's ratio if all layers have the same
dimensions, otherwise it's the image dimension ratio.
Also fixes a bug when trying to create the tool rectangle while multiple
layers are selected (the rectangle was always of size 0 at point 0).
Finally fixes the auto-shrink feature with multiple layers selected. The
rectangle will now auto-shrink to the smallest rectangle which
encompasses the contents of all selected drawables inside the existing
rectangle.
In gimp_edit_selection_tool_translate(), perform the active-item
checks even when the effective translation offset is 0, and only
bail afterwards. This avoids erroneously calling
gimp_tool_message_literal() with a NULL message in this case.
In file_open_image(), mount non-native files *before* looking up a
file-proc. Previously, we'd only mount the file after the initial
lookup, and fail to perform a second lookup if the mount succeeded,
leaving us with a NULL file-proc and a subsequent segfault.
Additionally, simplify the rest of the remote-file code-path.
Jacob Boerema