Adds import and export support for clipping paths in PSD files.
On import, path name and flatness value are saved in parasites.
Prior settings are loaded in the GUI on export.
Add a new type 'byte' to be able to handle binary data while still
retaining the utf8 char and string behavior.
Internally the file and string port and character handling have
been reworked to use the new byte-centric functions.
Also adds a new test script (test9) that tests byte, char and
utf8 string handling.
Only libgimpui depends on GTK+, display servers and other GUI-related
dependencies. There was a problematic include added in commit 0b56aa0d13 for
macOS, but the needed code (testing the macro GDK_WINDOWING_QUARTZ to use some
[NSApp activateIgnoringOtherApps:YES] API) doesn't seem to be present anymore in
there, so I think that removing this include (replace by including GLib for
other calls) should work fine. Of course, we'll know it when the separate CI
will test a macOS build as we still don't have in-Gitlab macOS jobs. :-/
This will allow to also check the list of runtime builds. We could see an
example in a report (#8993) where someone had the latest flatpak build of GIMP
but an older build of the runtime flatpak. So they had a bug because of a
dependency which got updated since then.
Add several missing help ids, remove those that are not used anymore,
and update "gimp-colorselector-water" to "gimp-colorselector-watercolor".
Also add a comment why some help ids are not used directly.
In the last few days, our deps-win64 job started to fail with:
> $ update-alternatives --set x86_64-w64-mingw32-g++ /usr/bin/x86_64-w64-mingw32-g++-posix
> update-alternatives: error: no alternatives for x86_64-w64-mingw32-g++
The reason lies in this change in Debian testing 10 days ago:
----
gcc-mingw-w64 (25) unstable; urgency=medium
* Upgrade to GCC 12. Closes: #1023679. It is no longer possible to tweak
the installation directory for different thread models, so the -posix
and -win32 packages are no longer co-installable.
* Drop “Built-Using” from “Architecture: all” packages.
* Since the POSIX and Win32 packages are no longer co-installable,
drop support for alternatives and use symlinks to provide the full
set of command names.
* Standards-Version 4.6.1, no change required.
-- Stephen Kitt <skitt@debian.org> Mon, 12 Dec 2022 09:00:34 +0100
----
So from now on, we'll only install the posix variant of the cross-compiler.
Hopefully it will work for all packages we build.
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.
Alx Sa