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).
While testing the relocatable code paths, I realized that
_br_find_exe_for_symbol() was always returning NULL. The reason is that
our code looking at /proc/self/maps was expecting that the searched
pointer would be in a "r-xp" memory region. On my machine though, it was
in a "r--p" region.
Maybe in some cases or some older kernel, the "r-xp" permission is/was
right, I have no idea, so now let's just not make any assumption on the
region's permission, where we expect to find our static string, i.e.
let's not do any test on the region permission anymore.
Even though it is set by Linux's limits.h and apparently by other OSes
too, it seems this macro is mostly bogus. On many systems, the actual
allowed max size of paths is much higher.
On Hurd, they don't even define the macro as there is no upper limit.
See MR !424.
This commit replaces two usages of PATH_MAX:
- readlink() by g_file_read_link(). I checked the GLib implementation
and could confirm it will do the proper thing, which is progressively
incrementing their buffer allocation in a loop until the buffer is big
enough to contain the symbolic link contents. Hence no need to rely on
a bogus macro which is not the actual max.
- fgets() by g_data_input_stream_read_line() which also dynamically
allocates the returned buffer, and also properly removes the newline
and adds a NUL byte (hence simpler code).
Additionally I loop through the lines of /proc/self/maps until I find
the first "r-xp" pathname. Indeed the current code was assuming that the
first line was always right. Yet on my OS at least, the first line was
GIMP executable with "r--p" permission, hence the test would fail. The
second line had the right permission. So let's assume that we want the
first executable path, looping through each line.
It isn't being used by any plug-in or any code in GIMP at all even.
Let's get rid of it while we can still break API, so we can cut down on
all the complexity of the gimp-param stuff a bit.
… gimp_parasite_data_size().
gimp_parasite_data() was non introspection friendly because calling code
needs to know the size of returned data a way or another (the concept of
data pointer with random contents, no known size and no way to know the
end of the buffer is not usable in many languages other than C).
Now that all usage have been replaced by gimp_parasite_get_data(), we
can just remove the functions from the v3 API.
Allow @num_bytes to be nullable, but add text in the documentation that
this is only useful when you want to check if there is contents.
Also make @num_bytes into a guint32, and finally set it to 0 when there
is no parasite.
In GIMP 3, plug-ins are mandatorily under a subdirectory. Though on GIMP
2.10.x, both cases are still possible. So only the previous commit
should be backported to gimp-2-10 branch.
See discussion in !392.
Thanks also to Christopher Nielsen for helping.
Although most GObject bindings can't really deal with struct fields,
it's still a nice thing to be able to see that these are actually arrays
(it also becomes visible in the Vala VAPI file).
Similar code was used in 2 places basically (GimpLabelSpin and
GimpProcedureDialog) so just make it an utils function. It's good anyway
to have a generic function to estimate suitable increments and decimal
places depending on a range.
As a consequence also gimp_label_spin_new() now takes a gint digits
(instead of guint), with -1 meaning we want digits computed from the
range.
Similarly gimp_prop_scale_entry_new() docs adds the -1 meaning too.
This is one of the problems mentioned in issue #5863. This commit only fixes
our loading (and saving) of this metadata.
Certain iptc tags like "Keywords" can appear multiple times. We were using
gexiv2_metadata_get_tag_string to get the value but that always returns
the first value so we replaced that by gexiv2_metadata_get_tag_multiple.
`man snprintf` clearly says (in NOTES) that when source and target
overlap, the result in undefined.
g_snprintf() conforms to the same standard hence would not get the
expected result. In my case, the result was just tzstr (e.g. "+01:00").
There were still a few references to functions which have been removed
from GIMP 3 (because they were deprecated in previous versions), which I
found as I was doing an inventory of removed functions.
Partially based on the comments of Massimo Valentini we block all Pentax and PentaxDng
exif Preview tags from being exported. We leave finding a more flexible solution for
problematic tags to a future contributor.
Plug-ins that work from different bindings probably want to use their
own list-type to specify arguments, rather than working with a more
cumbersome `GimpValueArray`.
This new API should make it less verbose. For example:
```
args = Gimp.ValueArray.new(5)
args.insert(0, GObject.Value(Gimp.RunMode, Gimp.RunMode.NONINTERACTIVE))
args.insert(1, GObject.Value(Gimp.Image, image))
args.insert(2, GObject.Value(Gimp.Drawable, mask))
args.insert(3, GObject.Value(GObject.TYPE_INT, int(time.time())))
args.insert(4, GObject.Value(GObject.TYPE_DOUBLE, turbulence))
Gimp.get_pdb().run_procedure('plug-in-plasma', args)
```
becomes
```
Gimp.get_pdb().run_procedure('plug-in-plasma', [
GObject.Value(Gimp.RunMode, Gimp.RunMode.NONINTERACTIVE),
GObject.Value(Gimp.Image, image),
GObject.Value(Gimp.Drawable, mask),
GObject.Value(GObject.TYPE_INT, int(time.time())),
GObject.Value(GObject.TYPE_DOUBLE, turbulence),
])
```
... by qualifying them with "extern", in addition to
"__declspec(dllexport)". Omitting "extern" happened to work in the
past, but recent GCC versions require it.
I assume that we won't need most of these explicitly in bindings, but
_if_ it's needed, then it's best to make sure that people don't struggle
because they don't have proper API without annotations.
Jehan