Adds option to export JPEG XL images in CMYK/A format.
Key and Alpha data is saved in extra channels, and the
simulation profile is saved as well.
Per the specification developers, the format does not
support 'naive' CMYK conversion, so a profile is required
for export. The option will be disabled if not set.
Checks if file has an extra key channel for CMYK. If so, it is combined
with the image's CMY image to create a CMYK buffer for import.
Color profile is stored as image simulation profile.
If alpha channel is present, it is now loaded as well for CMKYA images.
The URI will be: https://developer.gimp.org/core/maintainer/release/ (once we
merge the testing website to the main)
The new procedure also contains a wrapper step where we paste the checklist,
markdown-formatted, into a Gitlab report for better progress follow-up and also
onboarding testers into the release procedure.
The current code was wrong, hence was producing wrongly versioned shared
library files. This commit do it the same way as we do it on autotools build,
and additionally compute the library version (since "current:revision:age" gets
transformed into "(current - age).age.revision" by libtool, but meson doesn't
use libtool so we have to do this ourselves).
Now meson and autotools builds produce the same result at least. There are still
some points I'm wondering and which we should handle before GIMP 3.0 release:
* Since meson doesn't use libtool (and no .la files are created), should we
actually stick to libtool version scheme? It seems like some projects would
use semver instead. On the other hand libtool version gives a bit more info.
* Also it raises the question on whether we want the API version to be semver at
all or simply follow GIMP version? It used not to be much of a problem as we
wouldn't add features (hence new API) on micro version, yet now we can. So
GIMP program's version could not pass as semantic versioning. On the other
hand, having a diverging API version (whose minor version would increment
faster in particular, with regular micro version resets) would be confusing
too.
* If we keep libtool versioning, I'm thinking we should do it manually. It's
actually pretty easy with a good docs (or even just following GNU docs:
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html),
and simple to understand whereas the current code logic is very weird and we
end up with huge current and age values with complicated computation.
Note also that I raise the "Libtool versioning" section near meson.build top and
updated gimp_interface_age to be the same as on autotools currently.
- The <_p> or <_li> syntax for localizing AppData is the old code logics from
intltool.
- Mailing lists don't exist anymore. Move all usage on discourse.
- Microsoft Store is only for stable builds.
- Let's always merge `origin/testing` into `master` on gimp-web module (no
cherry-picking) as it's clearly the procedure we've been doing for quite some
time now.
GtkTreeView has an "interactive search" feature built-in, which basically kicks
in with the Ctrl-F shortcut by default. Let's hijack this feature and trigger
our own new search popover which is much more powerful (multi-item selection,
ability to use regexp or glob search by enabling these in Preferences, etc.).
This was an idea by Aryeom who wanted to be able to hit Ctrl-F to search for
layers.
These are typically debug outputs and we don't want them to appear on stderr of
release builds. They confuse people (some tester would report these on IRC when
we last release GIMP 2.99.14).
So let's not show these debug text on release versions.
Only the libwmf patches are still different. Apparently we may have fixed the
same bugs in different way on both branches. We should look later in details to
see if some patches are better than the other.
This adds a check to make sure icon is valid when displaying
the icons in order, to prevent duplicates showing there and in the
invalid list at the bottom
It's probably unneeded as the 2.99 installers are transient and anything
installed by GIMP 2.99 won't be in stable 3.0 anymore. Still, it's nice not to
have any weird warnings even in dev releases.
Kristjan SCHMIDT