Since the color space invasion, GimpRGB
properties do not create widgets anymore.
For Python plug-ins, we need to add
GeglColor properties as GObjects with
GeglColor value types as a workaround.
This patch does this and updates the
Foggify plug-in with the new datatype.
It is quite obvious that these were all kept around for the fun historical
background. And even though we can always get these back anytime through git
archeology, if these images disappear from our sight, we will just eventually
forget they even existed.
We now have a `gimp-data` repository for all data used and installed by GIMP. I
am not going to add these over there since it would go against the whole purpose
of splitting the source repository (we have too much data so we will want to
clone `gimp-data` as shallow so that it will only contain the necessary data to
install GIMP).
Yet I have created a page to reference and display all these original images
(and more! I spent quite some time researching old splashes and logos in our dev
log) for the pleasure of keeping the history of GIMP alive. It also reference
commit links for easy retrieval and further researches.
The only left images now are:
- gimp-logo.png and gimp-devel-logo.png: these are used in the About dialog or
API reference. Ideally they should be generated from the SVG source.
- gimp-splash.png: used as splash image, in the Welcome dialog and in the
Windows installer.
- wilber.png: only used in some Script-fu test scripts as far as I can see. This
should also be generated from the same source SVG as gimp-logo.png, or maybe
simply gimp-logo.png should be used instead.
Logos: https://gitlab.gnome.org/GNOME/gimp-data/-/blob/main/images/logo-log.md
Splashes: https://gitlab.gnome.org/GNOME/gimp-data/-/blob/main/images/splash-log.md
...with the Enter key. Combines the single image
and multi-image opening methods so that no matter
how you open recent images (single click, button, or
multi-select and pressing Enter), it opens all selected
images in the Welcome Dialog.
AFAIU the issue which it tried to fix only happens on custom builds and it looks
to me that it's just about multi-prefixes developer builds which were not
configured with -Drelocatable-bundle=no as they should.
When you compile GIMP yourself and intend to run it in a multi-prefix
environment, without ever relocating the build, like on Unix-like systems, then
disable this feature.
In any case, we should never do this kind of system file moving hacks in our
build system. The MSYS2 project even had to patch this out:
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1171#note_2022406
The indexed conversion code was originally written for very low-memory systems,
this makes the mapping it does quantized and noisy, for examples see issue
#5159 this commit removes quality/memory use trade-offs, modern machines can
take a 2-300mb temporary table allocation.
This is similar code to what I added for the Windows builds, except that here
it's because deps-debian-x64 will also end up feeding dev-docs job too.
Right now our tagged build of GIMP produces docs for unstable versions of babl
and GEGL.
Since !1171 we can use the CI scripts locally, but the initial implementation,
after some commits, revealed to be troublesome. So, now reworked to be simple.
As noted by Jehan, the way of defining the (many) GIMP versions can change.
So, let's take the GIMP version directly from the generated config.h file.
Also, changes the declaration of some variables to conform with "best pratices".
This list is referenced in the gimp-web-devel site, and my initial
implementation, in terms of ease to use, was a throwback.
Also, make the CI code more simple without changing the list file.
Alx Sa