Even the fact we have a libgimp gimp_quit() function which was not
calling the PDB proc of the same name (and indeed doing something
differently) was weird and confusing.
Anyway we should not allow random plug-ins to basically kill GIMP
without any way to do anything about it, and probably lose all your
unsaved work. This is just wrong IMO.
We'll see if anyone wants to disagree, since anyway this won't be
removed until GIMP 4.
Let's create the folder returned by gimp_temp_directory() ourselves, the
first time this function is called, using a randomized name. This will
ensure that we won't conflict with another user running GIMP on the same
machine if using the base /tmp/ (which is usually the case on Linux).
Furthermore, since we create the temp folder at this level, we will also
delete it when quitting (but only if it's empty, as it should). Also I
use a single-level folder above the generic temporary directory, this
way, it's easier to track and we don't have to delete 2 levels of
directories anymore.
When the environment variable GIMP3_TEMPDIR is set though, we do not
create the folder, nor do we try and delete it.
And use the function in script-fu. While we want wrong resource names to
trigger WARNINGs in Script-Fu scripts and plug-ins (because these can be
considered as a bug), we don't want it to happen when the resource is
not loaded on purpose (mostly it means that we run GIMP with --no-data
or --no-fonts). This was happening in our own builds when running GIMP
through the in-build-gimp.py script and that was always very annoying.
Now in such a case, we will only output an INFO message on stderr (it's
still a good idea to warn about this, because if we imagined someone was
running a script non-interactively, which called one of these
procedures, they may have relied on the default value of some arguments.
Therefore they'd want to know about such a behavior change).
The INFO message "a stray image seems to have been left around by a
plug-in" was annoying when GIMP is run non-interactively, and when it
was about images open from command lines. Typically this message would
be visible on our CI when the various gimp-data scripts would fail. This
could only confuse script developers.
The fact is that while a plug-in (or batch script) should definitely
clean after itself by deleting images it created (unless it gave it a
display, in which case ownership is moved to the GUI), it is absolutely
expected that images opened through the command line would still exist
at exit.
It is not a fix yet for #14681 but would provide nicer and earlier error
when a call to gimp_temp_file() fails, which may happen in some cases.
E.g. if the temp directory doesn't exist and we fail to create it.
As a test, if I delete /tmp/gimp/3.2/ and give root ownership to
/tmp/gimp/, now the error when opening our gimp-splash.xcf.xz is:
GIMP-Error: Opening '/path/to/gimp/gimp-data/images/gimp-splash.xcf.xz' failed: Error creating directory /tmp/gimp/3.2: Permission denied
… even when we have no display.
gimp_message() supports a NULL handler object and we get proper
GIMP-Error message printed on stderr, e.g. when GIMP is run from the
build system.
We want as much info as possible when debugging our build scripts.
This is part of fixes to improve situations such as seen in #16160.
In GIMP 2.10, the PDB call
gimp-context-set-line-width-unit allowed
for Pixels to be set as a unit. In 3.0, we
changed GimpUnit to be a proper object
and gave it options to allow pixels or not.
The default setting is 'no pixels allowed',
which caused the unchanged
gimp-context-set-line-width-unit parameter
to no longer accept pixels as a unit.
This patch adds `allow_pixel => 1` to the
PDB set-up for setting units to fix this
oversight.
Resolves#16019
The Edit -> Fill with... options did not respect if
layers could not be filled (such as linked layers or
multiple selected layers with some layers being
pixel locked). This patch adds checks instead of
unconditionally filling those layers.
It also adds the text & vector specific fills from 916cf84e
to keep this action consistent.
I noticed this yesterday, especially through gimp_image_get_active_array()
and gimp_image_get_visible_array() which are looping through
MAX_CHANNELS, hence assuming the passed components arrays are of
sufficient size. I could have just added some comment to document that
we must be careful when calling this, but this is currently completely
unused code. So I prefer to just clean it out.
If we need something like this in the future, we can just do it better.
Previously, when using shortcuts to increase or decrease the font size of
the selected text, the size would jump to 0. This behavior occurred because,
if the text did not yet have a font tag, the initial font size was evaluated as 0.
This commit ensures that the text tool's default font size is used when
no font tag is present. This prevents the font size from jumping to 0 the
first time the shortcuts are used.
Fixes when compiling:
> error: variable length array ‘mask_row_buf’ is used
With this and previous commit, we can now compile with C++ flags
-Werror=vla and get no build failures.
Fixing in the gimp-macos-inhouse: [arm64] job:
> ../app/core/gimpbrush-transform.cc:869:17: warning: variable length arrays in C++ are a Clang extension [-Wvla-cxx-extension]
Also adding some asserts in some places where we rely on the
MAX_CHANNELS constant so that we will quickly detect if this variable
needs to be further bumped in the future (especially as we will add
CMYK+ support as backend format).
When moving a floating layer or selection, we draw a solid
border around the object. However, we also let the "marching
ants" selection continue (if the user has it enabled). This slows
down performance when moving, especially on large selections.
This patch incorporates logic from the Selection tools into the
Edit Selection tool (which the Move Tool uses for translation).
It stores the user's "Show Selection" setting, sets it to FALSE
while moving the layer or selection, then restores it to its
prior value when the cursor is released.
This logic also extends to using Ctrl + Alt to drag a floating
selection out of a layer that already has a selection.
gimphistogram.c used its own custom MAX_N_COMPONENTS
define for the max value of its "n-components" property.
Since this value is the same as MAX_CHANNELS, it would be
good to use the global constant so the histogram limit automatically
updates when we added a new format with a larger number of components
such as CMYKA.
Try proxy bindings before the IM context. On macOS and Windows,
the IM context consumes Alt+key events (Option produces special
characters on macOS; Alt triggers alt-codes on Windows), so
bindings such as Alt+Plus/Minus (size) and Alt+arrows
(baseline/kerning) would never be reached otherwise.
eec9d512 did not block calls to
gimp_drawable_filters_editor_visible_all_toggled () when
updating the "All Visible" toggle button in
gimp_drawable_filters_editor_set_sensitive (). This resulted
in unexpected visibility changes in some combinations of
filters being turned on and off.
This patch adds the blocking calls around the call to
gtk_toggle_button_set_active () to keep this consistent.
This patch makes it so that you can click the preview for
Original and Rotated images in the Metadata Rotation Import Dialog,
and have it open the image rotated as shown in the preview.
This supplements the existing button options, and matches how other
software works.
When hovering over the images, the cursor turns into a pointer to
further suggest it is clickable.
Tab was intentionally removed from the action entry to avoid overriding
its standard accessibility usage across the software, leaving the menu
item and shortcut editor showing no shortcut. This adds a cosmetic hint
in gimp_action_get_display_accels() to show 'Tab' without registering a
real accelerator.
