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.
Fatal errors should not be done with g_message(), but by setting the
returned GError appropriately. The main GError must therefore be passed
through functions.
Some non-fatal warnings may still be outputted with g_message() if we
want people to be aware of them (for instance if we managed to load some
data yet there might have been data loss or errors).
Finally when we are confident that we recovered from the format error,
it is still nice to output some error on standard error (not be totally
silent about it), but probably not need to bother people with popups.
See #5357.
Also clean up C++-style comments into C-style, to follow our coding
style.
Note: I only cleaned ddsread as a continuation of commit 81a3370e1d. I
expect ddswrite to have similar issues, but I did not look at it.
File paths can contain confidential information such as usernames
and directory structures, making the previous behaviour a potential
privacy and security risk.
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.
After discussions on IRC, it was decided that our current level of
support of OpenCL was not good enough. As a normal settings, people just
see it as a normal acceleration checkbox, even despite the warning text
and emoticone saying the opposite (i.e. it may even slow things down in
some cases).
Basically this feature needs more love to be back into mainstream
Preferences.
This file is available in a flatpak sandbox and will contain various
info such as the build commit, very useful info as we can have several
builds for a same version. For instance if we have exactly the right
commit, we can load exactly the same binary as a bug reporter very
easily, hence are able to get source correspondance without necessarily
asking reporters to install debug symbols (though it stays easier if
they can do it).
Other interesting info contained in this file are the exact runtime
used, the installed application or runtime extensions, the permissions
(people may override our flatpak permissions so it's useful to be able
to check when they did) and environment variables…
Jehan