This mostly reverts commit 987dc52160
(with some conflicts fixed as the file got further touched).
This table was already properly aligned as what matters is the generated
INSTALL file, which is what will end up in our source tarballs. This
file is also published on the developer website. The reverted commit was
completely breaking the formatting. 😅
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
This is a further improvement, for the specific case which appeared on
issue #16160. Basically here for the specific case when we have
permission issues, or other similar issues where we fail to either load
the input image, or export to the temporary file, we would get more
explicit error messages. And this would also show in the stderr output
of the in-build-gimp.py script.
In particular, when reproducing #16160 permission issue, the build logs
now contain this error:
GIMP-Error: Opening '/path/to/gimp/gimp-data/images/gimp-splash.xcf.xz' failed: Error creating temporary file '/tmp/gimp/3.2/gimp-temp-1719540.xcf': Permission denied
This should better help diagnose similar issues in the future.
… 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.
Resolves#14583
If the user chooses to vectorize PDF layers with single colors,
get_layer_color () is run to use histograms to determine if they
are indeed a single color. gimp_drawable_histogram () is used to
get the RGB values as averages. This function returns values in the
0...255 range for 8-bit images and 0.0...1.0 range for all the
other precisions.
However, we did not properly normalize the values, resulting in
blown-out white layers when exporting 8-bit images. This patch
checks if the image is 8-bit and divides all values by 255.0f in
that case.
It also checks if the image is in linear precision or not, as
gegl_color_set_rgba () assumes the color values are linear. If not,
gegl_color_set_pixel () is used instead. Finally, the color mode
checks are made a bit more robust in preparation for future color
modes like CMYK.
We were using VCPKG_DEFAULT_TRIPLET, which makes impossible to
use x64-windows-release triplet since vcpkg starts to crosscompile
(even on the same arch). Let's fix this by using the right env var.
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.
This adds aalib, gi-docgen, libheif, libmng and vala.
The homebrew list was originally minified since all-deps-uni was
ported from the treatment of vcpkg on build/windows all-deps-uni.
But since on homebrew we don't build anything, let's install them.
This also adds to the list deps already installed recursively.
Resolves#16151
The original implementation mixed up the variable that
needed to be used for boundary checks - it should be
"estimated_size" and not "flags". This patch fixes the issue
to prevent a buffer overflow.
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.
Resolves#16150
Per Bronson Yen, it's possible to create a transparent chunk
that's larger than 256 index values. In that case, the trans[]
array will overflow since we initialize it to 256 indexes.
This patch adds a check to make sure the iterator used for the
transparency for loop does not exceed the array size even if
the chunk size does.
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.
