move core photo/light adjustment ops like exposure and color temperature to the
topmost section of the menu, and move the more artistic threshold, colorize and
posterize options to the bottom section.
Largely based on a patch by Ell, with the enum type renamed and
various small changes. Adds another axis of configurability to the
existing layer mode madness, and is WIP too.
Commit e518b97 broke Win32 compilation with a non-defined variable
"monitor". I made a dirty "fix" by using shootvals->monitor.
Apparently, seeing previous comment, that is probably not the right
value but Mitch is on it and I leave him work it out.
At least now it builds.
We can actually group modules together to mark their relationship,
and easily deactivate them together if needed.
I grouped all Python modules, Exiv2 under GEXiv2, ilmbase under
openEXR, and finally libpng and lcms2 under a "duplicate-dependencies"
module to indicate that these modules are available in the runtime
(under a lower version, below our requirements) so we should check
whether to remove them, upon runtime update.
The colon-separated list used in the plugin originally comes from
gimp_help_get_locales() anyway. My previous code was using different
lists of locales in different places, which was inconsistent.
Be a little cleverer about what locale we care about in the context of
the help system. Variants and encoding in particular are of no interest
to us.
Let's also always add a base language (like "en" for "en_GB") rather
than fully trusting g_get_language_names() since it seems to return
funny results on some platform.
Finally check for duplicates before adding to language list.
It seems that the Windows platform could sometimes return locales in the
form en-GB (so an IETF language tag, I guess) instead of a POSIX locale.
This little hack should take care of the easy cases until we get a
better and generic fix.
Add color management options to the screenshot plug-in:
By default, it tries to tag the image with the monitor profile;
alternatively, there is an option to convert the image to sRGB.
This works mostly fine on *one* monitor given its profile is
configured correctly. With more than one monitor, funny things happen
depending on the platform and on what we are shooting (window, screen,
area). There are some FIXMEs left in the code.
The build has been fixed by a patch from Upstream:
https://bugs.webkit.org/show_bug.cgi?id=156510
Note that WebKit takes hours to build, so if you just want to test
Flatpak, you may prefer disable this module again.
We now have a full-feature Flatpak build, except for libgudev, which
means that special input devices probably won't work in the GIMP
Flatpak. It is to be noted that Flatpak developers told me that
libudev won't work inside the sandbox anyway. A portal will have
to be implemented. See:
https://github.com/flatpak/flatpak/issues/12#issuecomment-276016074
The last stable WebkitGTK is 2.14.3 but that apparently corresponds to
WebkitGTK4 (which is already in the GNOME runtime). We need an older
version, and the last available would be 2.4.11.
I disable it though because the build failed in my test but let's save
my work-in-progress.
I know this looks absolutely horrible, please spare me comments about
that. This commit has the purpose to let everybody experiment with the
new modes, and suggest improvements of the GimpLayerModeBox widget; we
need *some* way of controlling the new layer mode madness.
Jehan