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.
This is necessary for opening files from the network.
It is actually possible to allow only some named service bus which
would be much more in line with proper sandboxing. But I can't find
exactly what is the service name used for gvfs (which is the virtual
filesystem apparently used internally for remote file access in GIO).
Also I'm pretty sure we must use other buses for various services. We
should make a list of what service bus are necessary for normal usage.
For the time being though, let's just have a flatpak build with as many
features as possible.
These variations on darken only and lighten only have the advantage over the
componentvise versions that they always use the full triplet of either original
or new layer - meaning no new colors/hues will be introduced. This is similar
to how these modes operated/operates in picture publisher and photo-paint.
- set the filter_tool->drawable before showing the tool gui.
- set the sensitivity functions for channel combobox of threshold,
levels and curves tools dialogs only once during dialog creations.
- use the filter_tool->drawable inside the sensitivity functions
Based on Alexander Larsson's original nightly GIMP flatpak. I updated
most dependencies, changed some options, and added some dependencies
whose versions were now too low in the runtime (libpng and lcms2).
I also use the new "--filesystem=xdg-config/GIMP" option, made upon my
request, which means we will want to use a recent flatpak.
Many options are still missing but that's a start with a working
flatpak manifest.
C++ won't allow us to use GimpLayerMode in the API where we used to
have GimpLayerModeEffects.
Move GimpLayerModeEffects to libgimpbase/gimpcompatenums.h so it's
not in the API any longer, and instead typedef and define stuff in
libgimp/gimptypes.h, and adapt the compat enum registering code
accordingly.
The porting from 8bit per component scaled some 8bit fractions up to huge
floating point numbers, this works for most values but causes trouble for near
transparent pixel values. This commit copies the inner blend loop from the new
divide layer mode, but keeps the old compositing logic.
... is fully transparent, instead of just src.
The blend func results only affect the intersection of dest and src.
Run time is currently dominated by the compositing step for most modes,
so the difference in performance is pretty negligible, but it does make
a difference for the more expensive modes, like the HSV ones.
The print size displayed in image property and title format should use
gimp_unit_get_scaled_digits() instead of gimp_unit_get_digits() and
adding 1, which is quite random or magic number-y.