gimpimagemetadata.[ch] was built into libgimpui because GTK+ was used
for dialog query for rotation metadata. gimpimagemetadata-save.c only
was built into libgimp, which made no sense as the declaration for its
public function was inside gimpimagemetadata.h!
That was a weird situation and somehow only made visible in the build
system because GIR build was complaining about missing annotations to
gimp_image_metadata_save_prepare() (the annotation was actually present
but in the implementation which was not in the same library as the
header, how weird!):
> Warning: GimpUi: gimp_image_metadata_save_prepare: return value: Missing (transfer) annotation
Moreover it means that only plug-ins linking libgimpui had access to the
gimp_image_metadata*() API, which is obviously not cool (that should be
a core API).
Instead I moved everything into libgimp and replaced
gimp_image_metadata_load_finish() with
gimp_image_metadata_load_finish_batch(), which is essentially the same
function except that it's not interactive (it will proceed to rotate the
image without user confirmation, provided the right flag is present).
Then I add gimpimagemetadata-interactive.[ch] which contains only
gimp_image_metadata_load_finish() and is the alternative interactive
version of gimp_image_metadata_load_finish_batch(). Most plug-ins won't
even have to be changed (at least none in core GIMP) and would still
work as before, whereas now a non-interactive version exists, which
doesn't mandate to link GTK+.
Current dev code of GEGL is necessary as it fixes its VAPI dependency
(see gegl!83). Without this, with a recent meson version, Vala plug-in
build fails.
See !334 for some more background.
This adds a blend mode for all known psp blend modes that were not
converted yet except for adjust.
I couldn't find any information about adjust and it's value of
255 suggests that it is not a normal blend mode.
Reduce number of undo steps created by Spryrogimp previews.
First, by grouping them into a single undo.
The implementation adds a function for clearing the
incremental preview drawing that is being executed as an idle task,
and closing an undo group in case the preview left it open (which
would usually be the case). A second way to reduce undos is
by generating a new preview only upon mouse button release of
scales in the UI, and not while dragging the scale.
So it turns out there are still a few bugs in librsvg position/size
computation. One of them is described in my comments:
https://gitlab.gnome.org/GNOME/librsvg/-/issues/250#note_900325
To work around them, I had to increase stroke width of a SVG <circle> to
be over 0.5px.
It now uses rsvg_handle_get_geometry_for_layer() instead of
rsvg_handle_get_(position|dimensions)_sub() which have been deprecated
in favor of the new function which returns accurate (double) positioning
and size.
Back when I first made this build tool, librsvg had several blocking
bugs to make icon extraction work properly. This seems to improve
nicely.
Nevertheless I still don't build this tool because after testing, more
bugs remain and icon extraction is still not right. Just updating the
code to undeprecate it but leave the build commented out for now. ;-(
See librsvg#134, librsvg#128 and librsvg#250 for bug reports following
these issues.
See commit 1e5cf10585.
I am reorganizing again a bit the global file with all icons to
experiment a bit again with icon extraction using librsvg (let's see how
the library evolve since last time I tried, a few years ago!).
Traditional -config scripts are awkward for cross-compilation, multilib
systems (lib/lib64), and multiarch systems like Debian; only one copy
of the -config script can be in the PATH. As a result, some OS
distributions are starting to deprecate or even remove them.
pkg-config is designed to be a replacement for traditional -config
scripts, and is cross-compilation-friendly: the PKG_CHECK_MODULES macro
looks for an architecture-specific executable like
x86_64-linux-gnu-pkg-config, which can look in an architecture-specific
search path for library metadata, before falling back to a generic
pkg-config executable.
As a bonus, pkg-config also compares version numbers correctly
(see #2454).
libwmf having pkg-config metadata seems to be a relatively new thing,
so I've kept the -config script code path too, using it if pkg-config
does not find libwmf.
Bug-Debian: https://bugs.debian.org/956183
Signed-off-by: Simon McVittie <smcv@debian.org>
AVIF import and export (need libheif >= 1.8.0)
High bit (10/12) import and export
Auto pre-select suggested output bit depth in save_dialog
NCLX color profile import (link with lcms)
Metadata import (link with gexiv2)
Plugin will not return GIMP_PDB_SUCCESS in case of failure to import file.
Our currently registered JPEG magics was using possible fields at the
start of the file (JFIF, Exif) in 7th byte. A JPEG provided in #5584 was
starting with yet another field (apparently some Photoshop-specific
field "Photoshop 3.0.8BIM") thus magics detection failed (and since
extension was wrong, the file was sent to another plug-in, hence loading
failed).
Looking further, it looks like the 3 first bytes are actually always
common to all JPEG and are the right magics/signature for a JPEG. These
3 bytes don't seem to be used by other formats as well according to my
research, which means we should not have false positives either. So
let's switch to this magics 0XFFD8FF at byte 0.
To build GIMP without vala the arguments "--enable-vala=no --with-vala=no"
must be used during the configuration process. If the --with-vala is not
provided the build process will still try to build some vala based plug-ins.
Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/5389
Piotr Drąg