Continuing 32d64ab1, this converts the
few instances of CMYK and HSL/A double
to float to match babl's precision.

Let's figure out what job is running using the predefined GitLab variables.

Only affects unstable build.

Move remaining items to Demos.
They have names like "Test foo."
They only install on an unstable build.

The ScriptFu>Test menu is only in an unstable release.
It is untranslated.

The ScriptFu menus don't need to be so deep.
The Demos menu is an appropriate place for test plugins.

If the Demos menu is not in the stable release and translated,
Gimp creates the Demos menu and it is untranslated.

Lloyd Konneker authored Apr 23, 2024 and Lloyd Konneker committed Apr 23, 2024

The "Sphere" plugin demonstrate all the widgets for arguments of a plugin.
Only its menu label is translated.

The "Hello World" plugin demonstrates an independently interpreted SF plugin.
It has no translations, even of its menu label.

Formerly in ..ScriptFu>Test menu.

They still are installed even in a stable release.
If we don't want 3.0 stable to ship with demos,
need more changes to meson.build.

They are akin to the goat exercise plugins.
These plugins are expected to ship with the goat plugins in a stable build.
!!! But 2.10 did not ship with any demo plugins in stable build.

There are duplicate "Sphere" (v2) and "Sphere v3" plugins.

Does not break string freeze.

The new-style "Sphere v3" plugin moves to Demos.
It will be installed with stable build.
No translations will change.

"Sphere" (v2) will only be installed in an unstable build.

FUTURE: we should translate Hello World and Sphere v3.
If they are to ship as demos, their GUI should be translated.

FUTURE: low priority we could rename "Sphere v3" to just Sphere,
and Sphere to "Sphere v2" so there is no conflict.

Partially reverts af79bbe0 (regarding .debug "extraction" in cross builds)

Now, we call the split debug script from the main bundling script, which makes
similar to our macOS .app bundling script. This cleans a bit of code in .yml
and make things clearer to the mere mortals in the scripts.

Its contents is a test plugin, "Test dialog".
I am responsible for it, and it is ugly, even in unstable.
Is only installed in an unstable build.

We need a convention that menu items for plugins named like "Test foo"
should only be installed in unstable build,
and should require no translations.

Note that if the Demos menu does not exist,
Gimp creates it, and it is not translated,
but only present in an unstable build.

Native arm64 and x64 TWAIN binaries are not built anymore. No need to
discard at dist time what doesn't exist. (32-bit TWAIN not affected)

Also, start to using our own ARM64 runners to do the dist. This is more
reliable since the shared x64 runners can (and indeed) cause long queue.

When there is a very long comment shown in the export dialog, the
dialog expands horizontally. Possibly making it wider than your screen
instead of wrapping the text.

Let's set word wrapping for the text view. That way the text will
wrap at a reasonable length and use the multiline text view instead
of just the first line.

They were generating a distracting output in CLANG* shells, as noted by
@lillolollo in a comment from MR: Infrastructure/gimp-web-devel!65

In the process, make AppImage and Windows (native) scripts use these
variables, without hardcoding the same variables from .yml anymore.

Fix ScriptFu, CRITICAL handling filename args user-entered in old-style interface.

Fix plugin, changes to API re Resource i.e. Palette and Colormap

Add message giving mangled name of output file.

Driveby minor refactoring of plugin.

Driveby cleanup, remove old email addresses.

Driveby use script-fu-use-v3 binding to PDB.

Resolves #10914

Some dockables such as "gimp-pattern-editor" and
"gimp-mybrush-editor" are listed as Editors even though
we don't yet have dedicated GimpDataEditors for them.
This causes problems when using certain features like
duplicating. To resolve for now, we check if
gimp_window_strategy_show_dockable_dialog () returns a
valid GimpDataEditor before trying to use it.
Per Jehan, we also verify that an edit button exists
and is visible before we try to call the edit command.

Jehan authored Apr 21, 2024 and Bruno Lopes committed Apr 21, 2024

Creating a temporary config directory for the in-build GIMP (run as a tool or
for unit-testing) is not done as a build target anymore, but in the
in-build-gimp.sh script as a unique temp directory, then cleaned out on exit.
This has a few advantages:

- It is properly cleaned out once the build ends (instead of leaving a full
  config dir as trash inside the build dir).
- It is not reused from one build to another (with risk of carrying bugs and
  issues over).
- Every use of the in-build GIMP will have its own config directory, and in
  particular when they are called in parallel.

As a side update, make sure that all `gimp_exe` runs depend on
`gimp_exe_depends`.

This is recommended by Microsoft for "*nix apps" and adding it to the
.exe manifest will avoid disparity between MSIX and other versions
(e.g. CI crossbuilds and CI native builds/installer/local builds).

See also: Infrastructure/gimp-web-devel!46

Jehan authored Apr 06, 2024 and Bruno Lopes committed Apr 21, 2024

Bruno note: This commit was repurposed after ad132ad0.

---

For some reason, on the Windows/Aarch64 runners only, submodule updates fails
with:

> + git submodule update --init
> From https://gitlab.gnome.org/GNOME/gimp-data
>  * branch            d1041a4d97871c85538938872d0ace69d2fc44c2 -> FETCH_HEAD
> error: Your local changes to the following files would be overwritten by checkout:
>         images/README.md
>         images/logo/meson.build
>         images/meson.build

The big question was: why are there edits to begin with? This is supposed to be
a brand new clone!
After a bit of investigation, it turns out that the whole files have incorrect
EOL endings (a `git diff` returns every possible lines in the whole
repositories, but `git diff --ignore-cr-at-eol` returns nothing). It looks like
this breaks the submodule update.

Jehan authored Apr 05, 2024 and Bruno Lopes committed Apr 21, 2024

Also update the gimp.rc and delete the committed fileicon.ico now that
gimp-data generates this file the same way as these PNG fileicon-s.

Jehan authored Feb 26, 2024 and Bruno Lopes committed Apr 21, 2024

Attribute uap4:ShellNewFileName is meant as a template file to be copied when
someone initiate the Shell "New" command (via the Explorer context menu).

Most of the work in this commit is by @Jehan.

These icons are used only by the .msix (MS Store) distribution of GIMP.

Some legacy icons are used only by Windows 10 and need to have smaller logo
than full image dimensions, so let's not use colorsvg2png. We just pass the
dimensions to use by configuring variants of the same base script.

The new dist job can produce two artifacts: a *.msixupload file
ready for submission and/or a *.msixbundle only for testing.

See the commit about the script for more details.

Jehan authored Apr 07, 2024 and Bruno Lopes committed Apr 21, 2024

This makes possible to debug with DIA SDK, if wanted by the developer.
Also, this is needed to create .appxsym files for MS Store debugging.

Ideally meson should be able to install for us, but apparently it doesn't.
See https://github.com/mesonbuild/meson/issues/12977

Adds PowerShell script and proper manifest for making .msixupload
(only for releases) and/or .msixbundle (always, for testing).

As authorized by Jehan, 32-bit willn't be supported. The reasons are:
1. 32-bit is going to die when WIA plug-in is done. This can hurt reviews
2. 32-bit is being restricted in ARM64 version. This causes disparity
3. 32-bit is generating a big footprint. "This is bad for the environment"
   To be clear: we are discarding most of 32-bit artifact (see point 1)
   and what could not (TWAIN for x64 only, point 2) almost doubles .msix.

There is one small circumstantial reason too:
4. 32-bit wouldn't have .pdb even after GCC 14 because bins have same name
   as x64, and MS don't allow multiarch debug symbols in the same .appxsym

Both in our Debian and Windows deps the openjpeg dependency was
missing, so let's add it back.

Though it's not visible and could happily wait for after GIMP 3 release, this
was annoying when grepping. Just did a quick cleanup.

I also removed gimprc.common which is a forgotten remnant from the autotools
build.

Per Pippin, the only color model that can
have double precision is RGB/A.
Therefore, we need to switch all others to
use float instead. This patch converts the
HSV and HSVA double babl formats.

As hinted in d09a2a6f

We now use the word 'bundle' to signify "program files in the same prefix"
(e.g. .appimage, .zip, .app). This is in line with our source and dev-docs
(just take a search in the repo). So, appimage and windows scripts changed.

The word 'package' normally means "program files distributed for install in
the same prefix or not" (e.g. .deb, .msi, .dmg). This is in line with CMake
naming of some commands, but meson prefers to call 'dist', which we use more.

So, this partly reverts some things of !1171 and reinforce others
for even more "rationality" in the overall build structure of GIMP.

… since forever anyway!

GIMP used to have a second export dialog, a generically generated one, appearing
either before or after (depending on when gimp_export_image() was called) the
custom export dialog implemented by the plug-in code. This has been hidden deep
in code since forever (since version 2.8.0 in fact, I believe) and only kept
hidden behind an environment variable "GIMP_INTERACTIVE_EXPORT". I don't think
we'll ever revive this, so let's clean up.

In fact, not one, but in worst case even 2 more dialogs were hidden behind this
variable! The first dialog (confirm_save_dialog()) was a confirmation when the
selected drawable was a layer mask or a channel (and not a layer). Most export
code don't even seem to care about the selected drawables anymore anyway (cf.
issue #7370), except with gimp_file_save() non-interactively (issue #8855),
which is a real mess of inconsistency anyway.

The second dialog (export_dialog()) was listing the various actions to do on a
copy of the image to help the plug-in (e.g. merge layers/flatten image, etc.)
and possibly give choices to some of these actions. Though there is definitely
no reason to request this kind of thing anymore, especially for a short-lasting
image copy, the list of action could still be interesting in the future, not as
information of what is going to be done, but as information of the kind of data
loss of the exported format. I could imagine we want to be able to reuse such
information for generating types of data loss per format in the export dialog,
in particular in the context of my long-term export workflow refactoring (from
which resizing before export such as #2531 are part of, but the whole
refactoring project is much wider).

In the whole discussion of #5858, there will be the question on whether we don't
want plug-ins to be directly given a "ready-to-use" image depending on
capabilities they advertized in create_procedure().

Should resolve #11370

Per Pippin, HSV double is not a valid
color model for babl. We need to change
to HSV float to resolve the warning when
selecting colors on the Color Wheel.

This is a well know problem documented in GitLab docs that happens when
the CI isn't properly configured that was causing double pipelines in MRs.
Let's fix it, and reduce some redundancy.

This line should have never been pushed (in commit a78c41d2), my bad! It was
an early (extremely ugly and bad!) attempt to try and have the bindings see the
libraries another way than using DYLD_LIBRARY_PATH (which was instead resolved
with commit 3e980d5a).

This omission went unnoticed until I add `set -e` very likely as this failed
command would stop the script in failure.

- gimp_rgb_list_names() ported as gimp_color_list_names() using NUL-terminated
  GimpColorArray.
- GimpColorHexEntry uses the new function (and is therefore now GimpRGB free!).
- gimp_rgb_parse_name() deleted as it's unused since my previous commit.

With all this, gimprgb-parse.c is now deleted from the repository! \o/