We were basing our max export size on a macro value defined in
libXCursor code: MAX_BITMAP_CURSOR_SIZE. This macro is still defined in
libXCursor and still has the same value (64), yet it is unsure how far
or even where this is enforced since it seems we can get at least 96px
cursors in GNOME/X11.
As a consequence, this commit:
- still warns when cursor size is over this value, with more explicit
text, yet does not change the cursor size anymore! So it is now
possible to export bigger cursors, but you still get a warning.
- only changes the cursor size for the existing more-than-8-digits test
and I add a warning when it does so (we should never modify an image
silently!).
- adds the size 96 as not triggering the warning about GNOME Settings
since it definitely looks like this size is valid there (according to
my own empirical tests). Also since 96 is higher than the libXCursor
current MAX macro value, this really raises the question to where this
max is enforced and whether we should not just drop the first warning.
Note that it breaks a bit the string freeze since I modify one string
and adds one. Sorry for this!
... removed by commit 0f9da165e0, and
improved by this commit.
Our foo-light modes aren't really prepared to handle out-of-range
input. Make sure that in-range input doesn't result in out-of-
range output.
Looks like ender's name can't be used verbatim in the encoding used
for the Polish translation. Use his name as previously appeared in
the Polish translation.
Add a safe_div() function to gimpoperationlayermode-blend.c, and
use it in the relevant blend funcs, instead of plain division.
This function clamps the quotient to some reasonable range, to
avoid infinities, and maps epsilon/... to 0, to avoid NaN. The
latter part results in similar qualitative results to the
corresponding legacy modes, when calculating 0/0.
After commit f51acf3bfb the python console no longer
initialized gimpui, because it is no longer part of module
initialization.
If the plug-in is run noninteractively and it imports
gimpui explicitely it is now necessary to call gimp_ui_init ()
at the right time
Oh blasphemy! The Wilber logo in the toolbox can now be disabled
directly via the Preferences dialog (on the Toolbox page).
The logo is staying enabled by default though. Long live Wilber!
...and present linear RGB Histograms
This is step one: implement the feature at all (without new defaults
or proper GUI, cough).
Add boolean "linear" properties to GimpOperationPointFilter,
GimpCurvesConfig and GimpLevelsConfig.
In the filter, simply set the input/output formats to linear in
prepare().
In the curves and levels tools, add "Linear" toggles from hell,
like in the histogram dockable, and make sure things work right
wrt changing and resetting the property, switching from levels
to curves, and picking colors.
The result currently changes when switching a non-nop curves/levels
between perceptual and linear, because adjusting the parameters
between the spaces is not implemented yet.
It appears that GTK+/GNOME don't have an icon with
"help-browser" ID anymore, but we have exactly the icon
that is needed for two menu entries.
Also, the menu entry for "Search and Run..." was using
a system icon for finding stuff, which looked wrong when
used with a symbolic theme.
We could come up with something overly clever like
a dedicated CLI/terminal icon, but people would expect
a magnifier instead (judging by what Blender does)
and that's what we already use for the Zoom tool.
Hence the lazy fix.
In legacy layer modes that may produce out-of-range output given
in-range input, clamp the result after blending and before
compositing, instead of after compositing, to avoid producing
different results than 2.8 in certain cases.
Improve the disabling/enabling of extended input events for the
canvas during enter/leave-notify events, in particular, so that
enter-notify events that are a result of pointer ungrabbing don't
erroneously reeanble extended input events.
Something about the unqueueing and requeueing of the entire event
queue during motion compression fries GTK's brain w.r.t. extended
input events. Instead, have gimp_display_shell_compress_motion()
return the first non-compressed event to the caller, making it
responsible for dispatching it after handling the motion event.
I didn't think I'd have to be this detailed, but it appears a lot of
people were not aware that data package .pc files would end up under
share/pkgconfig/ (and not lib/) and have problems with installing this
new "mypaint-brushes" dependency. Hopefully this will be enough.
