Add a new "Messages" boolean parameter to performance logs, which,
when set, records GLIB log messages in the performance log as
markers, with an accompanying sample capturing their backtrace.
This option is enabled by default.
... which set/remove a GLIB log handler for all domains used by
GIMP.
Use the new functions in errors.c, instead of using
g_log_set_handler() directly.
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.
Jehan