I added a lot more details about the API change. I'm sure I am still
missing many things but that still gives a good gist, at least of the
main API updates.
I don't list all the function changes (and will probably won't have the
time before release anyway), but at least the major changes. Some of
them actually triggered by themselves dozens of function signature
changes (for instance using objects instead of IDs or using GFile
instead of strings representing paths).
This is not a fix, only an extra-ugly workaround so that at the very
least we don't end up with a splash screen taking the whole display on
Wayland.
Basically by setting 1/3 as the max splash size, a Wayland desktop with
no scale ratio will have a splash taking a third of the screen while it
would take 2/3 of the screen with a scale ratio of ×2 (of course, it
will still be very broken with a scale ratio of ×3 but are there
displays needing such high scaling?). The real fix will be when GTK/GDK
fix their API so that it returns what the docs says it should (i.e. a
size in "application pixels" not "device pixels"), as it does on X11,
Windows, macOS… Then we won't create random max size and we will be able
to properly control our splash size.
Note that this neither fixes nor works around the position issue on
Wayland (in my case, the splash was just always on top-left of the
display).
These small glitches have bothered me for a while now, so I finally
fixed these before the dev release!
Basically there were 2 fixes:
1. use the ink extents to compute any drawn area as this is what will be
actually drawn.
2. Not only expose the drawn area of the new text, but also the one of
the previous text in order to be sure all text pixels are correctly
reset (in case the new text is smaller than previous one). I.e. we
must expose the smallest rectangle containing both previous and new
area of text.
We didn't check whether TIFFSetDirectory succeeded nor did
we check TIFFReadScanline for failure which can cause
unresponsiveness.
We will not try to read a tiff page if setting its directory fails
and we will stop reading a page if reading scanline fails.
I took the icon directly from Adwaita repository as of today's version:
https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/blob/master/Adwaita/scalable/status/software-update-available-symbolic.svg
By being installed on our local GIMP-only hicolor, this gets picked up
after any custom theme software-update-available version. I didn't
install it inside the Symbolic or Color theme because anyway Adwaita
seems only to provide a single vector version. There is a color version,
yet as PNG icons and installed in the legacy/ section. I don't think it
makes sense to use an icon considered as legacy by its author and
without vector version. So I just install the symbolic version and all
themes can fallback to it (be them symbolic icon themes or not).
This icon comes from the Adwaita repository and is therefore licensed
under the terms of either the GNU LGPL v3 or Creative Commons
Attribution-Share Alike 3.0 United States License. See:
https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/blob/master/COPYING
Since obj->type_data is also int anyway, multiplying by a double value
is unneeded anyway. So let's just make an integer multiplication.
Fixes the following warning:
> warning: using integer absolute value function ‘abs’ when argument is
> of floating point type ‘double’ [-Wabsolute-value]
The correct tag for sub images is Exif.SubImage instead of
Exif.Image. I also added Exif.Image.InterColorProfile since
that didn't seem to get deleted when saving without
color profile.
Also added a FIXME note since most of this stuff should be
genealized for all gimpmetadata handling.
Saving metadata was added inside the loop where the flags for
the differen types of metadata etc. to be saved were updated.
This caused multiple calls to save metadata with inconsistent
settings.
`gimp-2-10` branch has a common load procedure for HEIC and AVIF, but
the main file-heif contributor (Daniel Novomesky) considers it better to
have 2 procedures. Among other things, it helps to allow using a
separate plug-in for AVIF while this procedure is still used for HEIC.
This won't be backported to 2.10 because it changes the existing
procedure usage. So it's a master-only change, hence adding it to NEWS.
As AppStream docs says, <description> "tag should be translated
by-paragraph" in upstream metadata, which is what we have always done
(i.e. <_p> tags which becomes <p xml:lang="xy">).
Unfortunately as_app_get_description() is optimized to work for
Collection Metadata where the 'tag is translated "as a whole"' (again
cf. specs) for faster parsing. So we were ending up with a text mixing
the original and all localized texts.
I have opened a bug report to appstream-glib:
https://github.com/hughsie/appstream-glib/issues/381
While waiting for this to be fixed (i.e. when the function will handle
both cases accordingly to the metadata source), this code makes my own
locale extraction (defaulting to original text which is assumed to be
the previous same level tag with no xml:lang if no tag with the exact
lang attribute was found).
I really don't like to flag the distcheck job as allowed to fail, but
the issue we have with it right now (#5790) is very annoying and I have
no idea where the weird uncleaned files come from. I can't reproduce
this locally and these files are seemingly never created here during a
distcheck.
Since it makes all our pipelines fail, this makes it harder to diagnose
and find real other bugs, so let's allow failure until we figure this
out.
Make sure we regenerate the appdata file when po files are updated. It
should not be too much of a problem for release builds made from
scratch, but on incremental dev builds, the appdata was not regenerated
even when new translation got added.
Stable versions (i.e. minor version number even, e.g. 2.10.22) will only
look for higher stable releases. But for unstable versions, we will want
to look up the development releases too. So for instance GIMP 2.99.2
will warn if the development version 2.99.4 has been released, but also
if the stable version 3.0.0 has been released (whatever is the highest,
which is the stable version in this example).
I had recently created gimp_item_is_ancestor() but realize it duplicates
gimp_viewable_is_ancestor() (which works on GimpItem since it's a parent
class). No need for duplicate code.
Note that profile support also affect AVIF but since AVIF support came
anyway after libheif 1.4.0 (which is when color profile support
appeared), there is no way to differentiate there.
Thanks to Darix for noting the miss.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/5787#note_938976
Thanks to Wormnest for pushing me to look further. Since gimp-file-save
is actually redirecting the call to another procedure (save proc for the
specific format) which might have more arguments, including string
arguments. When it finds any, it sets it to an empty string "" (which I
guess is ok as "default value when we don't know what to put there").
The previous code would not hurt. Starting at the fourth argument
(GFile), it would just do nothing, then continue with the firth and
further. Still, starting directly at the fifth arg is the proper code
for this.
libheif pc files provides variables which are actually older than our
minimum libheif requirement (so it's usable generically) to determinate
if libheif was built for HEIC/AVIF support. This is quite useful as we
had our share of annoyance with missing support of some encoder/decoder
even when libheif requirement was alright.
Also adding image/avif (if relevant decoder is present) to list of
supported mimetypes.
