Commit e735054347 clearly shows that gimp_range_estimate_settings() can
be improved, but it would not be possible unless we added some argument
to know if the increments are meant for an integer widget.
Normally the error should not be NULL if file_open_layers() returns no
layers. But just in case, in order not to crash when we could avoid it,
let's double-check.
...in GimpRGB format.
Resolves#14754
GimpGrid properties are saved and loaded
in XCFs as GimpParasites. When we
converted from GimpRGB to GeglColor
for the fgcolor and bgcolor properties,
we caused those properties to be lost
when saving a 2.10 and below compatible
XCF in GIMP 3.0+.
This patch adds new
gimp_config_get_xcf_version () and
gimp_config_set_xcf_version () API to
libgimpconfig's interface. This allows us to
pass the intended XCF version to the
parasite serialization process, and save
as either GeglColor or GimpRGB compatible
formats based on that value.
In INTERACTIVE or WITH_LAST_VALS modes, the arguments were replaced by
the latest values, which is typically not acceptable for this specific
plug-in. Even in interactive mode, we still want file descriptors to be
set explicitly, and used by the plug-in.
This fixes such error I had on terminal:
> (busy-dialog:193133): GLib-WARNING **: 20:34:43.692: ../glib/giounix.c:414Error while getting flags for FD: Bad file descriptor (9)
And the worst part was that it sometimes prevented the busy dialog from
quitting (though sometimes it still exited fine despite the wrong file
descriptors 🤷).
Though the crash in #14139 won't hopefully happen again, thanks to my
previous commit, these additional assert may help in debugging if ever
it does again. Because truth is that even with partly-loaded fonts, this
was weird. If we had a GimpFont already, why did we fail to get a pango
font, or to query its file path through fontconfig?
This reverts commit 4b0f0cf820.
I forgot that we do not have mingw32 package for graphviz and
the vcpkg package started to fail out of the blue on MSVC.
In 84ff512c, we made the SVG id attribute
conform to SVG standards by using a
generic ID. However, we also relied on
that field to rename the path when copying
and pasting in GIMP. As a result, the path
name was lost.
This patch adds a <title> element inside the
<path> element, per David Gowers.
This allows us to retain the original
path name when copying and pasting
paths within GIMP itself, as this also adds
a check to see if there's a title element and
uses that as the path name.
This is needed to use im-quartz.so
(It will make no difference on the current gimp-macos-build scripts but it was
already not being defined so fine. It will work in the upcoming new scripts)
Resolves#15632
Since our code expects WEBP time to be measured in
ASCII "ms", translating it causes the time between
frames to be ignored. This patch reuses the string from
the GIF loading plug-in so that we always add milliseconds
as "MS", per Daniel Plakhotich.
Setting a step/page size of less than one for a spin scale bound to an
integer property does not make sense. Similarly the number of decimal
digits shown can be set to 0.
This was happening when trying to load a file before fonts were fully
loaded, which may happen when loading while starting GIMP (either from
CLI, or from a file browser, etc.), or simply just after start for
people with a lot of fonts, whose font loading may take a long time as
background task.
Note that I didn't manage to reproduce properly because from reports, it
seems like the problem appears where some fonts may be only partly
loaded so gimp_font_get_hash() fails to load the font and get a hash. I
never managed to trigger such a case and no reporters answered my call
for testing of debug builds.
As a consequence, I'll just assume that simply waiting for all fonts to
be loaded before starting to load images would work out.
Note that the crash was not happening when text layers were using the
older syntax (pre-XCF 19) of text layer data, since it was not storing
any font hash, which means that we were not trying to compare hashes. It
would also not crash if fonts were not fully loaded yet, but we didn't
have any weird intermediate state where fonts appeared in the list yet
their file were not hashable (cf. what I failed to reproduce, as
explained in previous paragraph). But both these cases were not ideal
either anyway because then we could load the XCF apparently OK… except
that the correct fonts would not be associated to the related text
layers (hence as soon as you start to edit said texts, the rendering
would break). So we should wait for fonts to be loaded, and that was a
bug even when you can't reproduce the crash.
When starting GIMP without loading an image, or simply when fonts are
loaded quickly enough, it won't make any difference. So it should not
make startup any slower for most common use cases and installations.
Even if we may have to wait for some feature, we may not want to freeze
the whole GUI. And this would also avoid the dreaded popup dialog from
the system which makes it look like the application is broken.
Finally in an upcoming commit, it will prevent the interface from not
being presented at all when loading images at startup (while fonts are
not loaded yet).
...lossless WEBP export
Resolves#15625
Per Daniel Plakhotich, we should use
WebPConfigLosslessPreset () when saving
lossless WEBP, so that the lossy quality settings
defined by the user don't override the lossless
values and unintentionally change the exported
file.
psd-image-res-load.c:1614:33: warning: variable 'init_fill' is
uninitialized when passed as a const pointer argument here
Although where it is used it is initialized in the function call,
let's fix it to get rid of the warning.
Seems this was the last .sh script pending to ported. Since I was experiencing
problems with the .sh one (not working locally nor on HomeBrew), I just ported.
Now, it is easier to read and fix if needed.
I also fixed the build order on libgimp meson.build to ensure the patched
.typelib being always present at the time GIMP generate splash screen etc.
We do check for python with import('python').find_installation() then
check for GI module support for introspection. However, this python is
not necessarely the one that will be found by .py plugins at build-time.
That is because the found python by Meson can not have a python3 symlink
but the python3 symlink is the one in-build GIMP uses fowlloing the shebang.
So, to we proper build GIMP on such environments, we can create a symlink.
That is needed for MacPorts where multiple pythons exist without a symlink
but this is useful for all environments because python3 is now unambiguous.
We were already considering the plugins under /common but
not the plug-ins that have their own subdirectories. So,
plugin_executables did not match custom_plugin_targets and
the build started to fail on macOS where install_name_tool
neeeds to process the plugins setting the right LC_RPATH.
lang() XPath function selects too much because when used with a base
language, because it would also select any sublanguage. E.g. lang('pt')
selects both 'pt' and 'pt-BR'.
See: https://www.w3.org/TR/xpath-10/#function-lang
