As per the changes in commit 005b3a05b8 and discussions in !800,
gimp_locale_directory() returns a string in the OS encoding for all but Windows
(UTF-8), i.e. the "filename" type in GIR annotations.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
Generated *enums.c now have an additional stamp no-op header include
(see last 2 commits). Sync this change into the autotools generation
scripts to prevent back and forth useless generation of these files each
time we switch from one build system to another.
They are nearly the same as initially, except that now they include an
intermediate stamp header which will be generated by the build system.
The only 2 enums which don't need these includes (and are not versioned)
are libgimp/gimpenums.c and libgimpthumb/gimpthumb-enums.c.
Our meson build system was not properly building the enums.c file,
because they are versionned.
I did a similar trick as what I did for the pdbgen, which is that I used
a wrapper script around the existing perl script, which sets proper
options and generate a stamp file in the end (which is considered by
meson as the actual custom target, not the C file since it is generated
in the source dir).
The most important part is that the stamp file is a generated header
source (not just a random text file) which is **included** by the
generated C file. This is what will force meson to regenerate the C file
if the header is updated, **then** build using this new version, not use
an outdated versionned version (which would make for hard to diagnose
bugs), through the indirection of the intermediate stamp header.
See #4201.
See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
In other cases we need to free value, but in this case it was used and
trying to free it caused a GIMP to crash.
Let's duplicate value, so we don't need to special case our g_free.
In the original gimp-2-10 branch where this feature was originally
worked on, we had to keep gimp_checks_get_shades(). But on `master`
where we will reset and break API, let's get rid of this function which
should not be used anymore.
Since we changed it, the version must be incremented too. It means that
third-party developers will have to rebuild their plug-ins.
Fixed Conflicts from !274:
libgimpbase/gimpprotocol.h
- Slightly nicer layout for the checkboard color widgets.
- Also set the 2 color widgets insensitive when the check type is not
GIMP_CHECK_TYPE_CUSTOM_CHECKS.
- Default the custom colors to the same colors as the basic default
grayscale. I mean, red and blue defaults are fun and all, but that's
like radioactive colors burning the eyes! Ahahah!
- Unlike the gimp-2-10 commit (cf. !274), on the main dev branch, use
the new GimpLabelColor widget.
Fixed Conflicts from !274:
app/dialogs/preferences-dialog.c
- Some coding style fixes (alignment, etc.).
- Adding missing "Since: 3.0" annotations. We are still wondering
whether this should go in 2.10, in which case, it would become
"Since: 2.10.32" annotations. See discussion in !274.
- Changing gimp_checks_get_colors() signature: merge the 4 color
arguments into 2 (inout) arguments which seems a bit nicer in C,
whereas binding handles such arguments correctly. The other
alternative would have been to at least change the order to have out
arguments in the end.
I also hesitated to get another API in libgimp, which would have been
config-aware (just returning the 2 check colors, depending on user-set
Preferences), then having GimpPreviewArea handling 2 colors (without a
GimpCheckType input). But actually, doing this, we'd remove the nice
menu popup where one could choose a generic check type (not everyone
wants to play with specific non-gray colors) in Gimp*Preview widgets.
So in the end, I left this whole thing as-is.
Instead I document the function with code sample to initialize
properly the GimpPreviewArea (since libgimpwidgets/ are independent
with no knowledge of the core config) in order to respect user
preferences.
- Hide the color properties in gimp_preview_area_menu_new() because
anyway gimp_preview_area_menu_new() does not support GimpRGB
properties right now (so all we get are warnings). It's still possible
to select custom colors on GimpPreviewArea, simply we are stuck at the
ones set in Preferences globally for now (unless a plug-in creates
custom GUI to set these).
Fixed Conflicts from !274:
libgimp/gimp.h
libgimpwidgets/gimppreviewarea.c
Reviewer (Jehan) note: cherry picked from MR !274. Still deciding
whether this will be pushed to gimp-2-10 branch too.
Fixed Conflicts from !274:
app/dialogs/preferences-dialog.c
app/display/gimpdisplayshell-draw.c
app/plug-in/gimppluginmanager-call.c
libgimp/gimp.c
libgimp/gimp.h
libgimpwidgets/gimppreviewarea.c
libgimpwidgets/gimppreviewarea.h
libgimpwidgets/gimpscrolledpreview.c
with many Xmp.photoshop.DocumentAncestors tags
This is similar to #7464, but in this case the XMP metadata was already
included in an XCF image.
We check for the occurrence of Xmp.photoshop.DocumentAncestors and stop
handling values when there are more than a 1000.
It would be easier to just check length for all tags and always
ignore when there are more than a 1000 values.
But in that case we would need to be sure there are no valid reasons for
tags to occur more than a 1000 times. So let's just limit it to this
specific tag.
NULL is not a proper value for GStrv yet we cannot escape it in the PDB
since we generate default values for non-passed arguments (especially in
interactive case where most procedure arguments aren't set). And for
such boxed type, it will be NULL.
So when we see a NULL GStrv parameter, let's not ignore it (which will
just crash the plug-in). Simply transform it to a GStrv of size 0.
GLib has a specific type of NULL-terminated string arrays:
`G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`.
By using this type, we can avoid having a `GimpStringArray` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GStrv`, we allow other languages to pass on string lists as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with string arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
There are still deprecations going around but for GExiv2 0.14.0 so we
can't change these yet.
Note also that I try a slightly different approach as I don't set a
GError for well-known tags as there is no reason these fail. I only add
a GError when we construct tags or similar calls.
I was waiting for GExiv2 to merge a patch I submitted:
https://gitlab.gnome.org/GNOME/gexiv2/-/merge_requests/20
Then we waited for it to land in a released version then for this
version to be in Debian testing. It's all done now and we bumped the
GExiv2 dependency in the previous commit (which makes it a master-only
fix). So all good.
Some images have huge amounts of XMP tag Xmp.photoshop.DocumentAncestors.
In certain cases more than 100000 values. This is apparently due to a bug
in certain versions of PhotoShop.
This makes deserializing it in the way we currently do too slow, probably
because of continuous reallocations after adding each value. Until we can
change this let's remove everything but the first 1000 values when
serializing. I think it is very unlikely there are any real cases where
more than a 1000 ancestor documents are referenced in an image. Testing
shows that this amount doesn't cause any serious slowdowns.
In some conditions, and only with some installations, the called GDB
ends up hanging and never returning. Worse, even if you use non-blocking
functions such as poll() or select() with a timeout, in order to wait
for the debugger output, these block anyway and never return.
We are currently unsure what exactly causes such problem, but not using
the thread command in gdb avoids it for now.
This is a bit of a regression, though most of the time anyway the useful
traces are the main thread ones (I think ever since I implemented this,
there must not have been more than 2 or 3 cases where we actually needed
the secondary traces). So it's acceptable, at least for now.
Otherwise if we add a NUL byte after the last byte, we might right past
the allocated memory. Thanks to Massimo for reporting this error raised
by Address Sanitizer and valgrind (cf. #7539).
In cases where the whole EXIF MakerNote is invalid we still load that
MakerNote data and export it too, causing partial invalid EXIF metadata.
We don't need to explicitly save Exif.Photo.MakerNote at all, because
as soon as we try to save a brand specific tag exiv2 will create that
MakerNote tag itself.
So from now we don't save the MakerNote but only the tags that go in it.
In issues like #2159 where exiv2 doesn't parse all tags inside certain
brand specific MakerNotes correctly, we will still export invalid EXIF.
That is an exiv2 issue that we can't do much about unless we remove all
MakerNote metadata including those that we can read, which doesn't seem
like a good idea at all.
On Windows when exporting an image saving the exif and other metadata fails
if the path or filename includes non ASCII characters.
Reason is that gexiv2 changed to using utf-8.
In the past we had to convert the filename to current locale on Windows,
but since it now also expects utf-8 there, just remove the special
handling of filename there.
This patch fixes a double free error due to a pointer being freed and
then not nulled out.
It appears this is corrupting memory on MacOS as the `/proc` file system
is not available and therefore multiple errors are returned.
Fixes:
(process:54873): GLib-WARNING **: 23:09:25.976: GError set over the top of
a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL
before it's set.
The overwriting error message was: Error opening file /proc/self/maps: No
such file or directory
_br_find_exe: (NULL)gimp-console(54873,0x100957e00) malloc: *** error for
object 0x103f09e80: pointer being freed was not allocated
gimp-console(54873,0x100957e00) malloc: *** set a breakpoint in
malloc_error_break to debug
When saving XMP metadata were using gexiv2_metadata_get_tag_string for all
tags, even those that can have multiple values. This caused those values
to be saved as one value instead of multiple.
To fix this we use gexiv2_metadata_get_tag_multiple, except for XmpText.
Then we add all returned values for that tag separately to our metadata.
Since it appeared with GLib 2.68.0, we could not change this until we
bumped the dependency which has only become possible a few days ago
(since Debian testing is our baseline for dependency bumps). Cf.
previous commit.
As this is a drop-in replacement (just a guint parameter changed to
gsize to avoid integer overflow), search-and-replace with:
> sed -i 's/g_memdup\>/g_memdup2/g' `grep -rIl 'g_memdup\>' *`
… followed by a few manual alignment tweaks when necessary.
This gets rid of the many deprecation warnings which we had lately when
building with a recent GLib version.
On Windows loading metadata from images with non ASCII characters in their
path failed. Part of the fix is in gexiv2 that now converts the path from
utf-8 to utf-16 on Windows.
However we were still sending a localized path to gexiv2 where it was
expecting utf-8. This caused the conversion and thus loading of metadata
to fail. Fix is to remove the special handling for Windows and use the
utf-8 filename.
As discussed in !455: remove duplicate testing, testing header and
testing the library are a same test in one (for instance we don't want
to get into weird cases where the lib is found but not the header; this
updated test takes such inconsistencies into account). Also it's better
to have all dependency tests together in the root meson file.
Finally adding some comments to make this all more understandable for
anyone looking at this in the future.
Without the (element-type), parasite cannot be created in at least
PyGObject binding (I have not tested parasite creation in other
bindings) and we end up with such error:
> ValueError: Pointer arguments are restricted to integers, capsules, and None. See: https://bugzilla.gnome.org/show_bug.cgi?id=683599
With this change, we can create it from a list of ints (e.g. for a text,
encode it into UTF-8 bytes).
… and s/gimp_parasite_flags/gimp_parasite_get_flags/
It is better to have a consistent API and the fact is that most
getter/setter functions use the _get|set_ naming, but these didn't.
I wondered if this was such a great idea to rename these anyway because
even though we are breaking API in GIMP 3, is it the best idea to rename
when no functional change happened? After discussing with Wormnest, we
still agreed it was still better to go for consistency rather than
regret later (and be stuck with these names for many more years).
Also this fixes these warnings:
> [649/1205] Generating gimp-3.0.vapi with a custom command
> Gimp-3.0.gir:24162.7-24162.56: warning: Field `Gimp.Parasite.flags' conflicts with method of the same name
> Gimp-3.0.gir:24318.7-24318.52: warning: Field `Gimp.Parasite.name' conflicts with method of the same name
This will be used by plug-ins to advertize their usage. Until now, we
were assuming that a plug-in wants a single drawable selected. Yet
multiple drawables can be selected now. Moreover even this information
is not so useful as many plug-ins don't care about what is being
selected. There is possibly even plug-ins which don't care whether an
image is opened (a plug-in to create new images for instance).
Note that this new type is skipped from the PDB because it is used as a
mask, hence not necessary, and was breaking script-fu (which was
incrementing through enums, hence assuming successive int values, not
bit mask values).
Jehan