I'm still very unclear why exactly but it would seem that just queuing
the redraw with an idle function is not enough. At least on Windows,
Jacob was having cases where opening an image would get stuck unless the
mouse was moved (causing draw events most likely).
So let's use a timeout function instead. Probably no need to queue the
idle followed by the timeout function as we had before commit
4fee04b839. Instead just directly queue a draw if relevant, then run the
timeout at regular interval (marching ants speed).
(cherry picked from commit 668c9de5a5)
This way, we would queue a lot less canvas region unnecessary redraws.
We still remake the time-before-last-draw check in the draw() signal
handling before we want to update the marching ants index for draw
events coming for other reasons (canvas updates, moving/zooming on
canvas, exposition changes, etc.).
(cherry picked from commit 6466d46052)
… displayed.
We should use the dimensions from the GimpDisplayShell not the the
GimpCanvas. Indeed the canvas is shorter when rulers are visible, hence
the selection next to the extreme sides (bottom and right sides of the
canvas) was not drawn.
(cherry picked from commit e8a531e51e)
As suggested in a comment (itself coming from an IRC discussion), we
should not use gdk_window_(begin|end)_draw_frame() functions as this
works on X, but not on Wayland anymore. Instead draw directly during
draw() call of the shell widget, and force it to happen regularly, to
update the marching ants, via gtk_widget_queue_draw_region().
This is tested and works on Wayland. Please everyone, test thoroughly to
make sure it works well in all situations, and also that we don't get
any unexpected slowdowns.
Since the symptoms are very similar, it is highly possible that it also
fixes the issue #5952 too, for selection not showing on macOS since Big
Sur 11 (maybe they changed the same way as Wayland did). Unfortunately I
can't check this myself. Please test, whoever has access to a macOS Big
Sur and can build GIMP!
(cherry picked from commit 4fee04b839)
… apply to GIMP GUI not text layer rendering in image.
Reviewer note: this is the theoretical fix, but it won't work right now
because Cairo explicitly bypasses grayscale antialiasing when system set
subpixel one. Still let's push this first patch, but the issue will be
actually fixed when Cairo will merge my MR too:
https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/114
(cherry picked from commit 00bbeabaf4)
XMP array tags of type BAG and SEQ can have multiple values, each of
which is on a separate line. However, we were reading and saving it as
just one value.
We change this by setting each line as a separate value with
gexiv2_metadata_set_tag_multiple.
In addition to that we found that setting the type of tag struct with
gexiv2_metadata_set_xmp_tag_struct caused arrays of multiple values per
tag to be set incorrectly: the last value in the list got added multiple
times. I'm not sure if we are using this function incorrectly, or that
there is a bug in gexiv2 or exiv2. Anyway, since it seems that all tags
and values I tested work without calling this function, let's just omit
this call.
(cherry picked from commit a4cb134f14)
XMP array tags of type BAG and SEQ can have multiple values, each of these
values needs to be on a separate line to be correctly recognized as a
different value in the tag array. We were incorrectly loading all values
on one line separated by a comma.
For those tags that have equivalent IPTC tags we were also comparing just
the one XMP value with the whole, possibly multiple lines, of the same
IPTC, which could cause a failure to recognize identical tags.
We changed this to now have each value in a tag array on a separate line
by adding \n between values.
Each IPTC equivalent tag value is now compared to each value in the XMP
tag array and only added when a different value is found.
(cherry picked from commit 76dc649b3f)
XMP tags that have multiple values (usually of type XMpBag or XmpSeq) were
shown on one line. Which, especially for long text values, could make it
difficult to see the separate values for that tag.
Let's do the same as we do for IPTC tags that can occur multiple times and
show each value on a separate line.
(cherry picked from commit baaa1380cf)
In the metadata-viewer refactor the code that adds multiple values per tag
to the list store into a separate function.
Currently used for IPTC tags only but the intention is to reuse it for
XMP tags with multiple values.
(cherry picked from commit e9ab89fa4f)
# Conflicts:
# plug-ins/metadata/metadata-viewer.c
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.
(cherry picked from commit af888e481f)
