... tools' brush options.
After discussions, it turned out that many people disliked that the spin
scale for brush size (and some other options) get you fractional values.
How often do you actually need to get a 4.32 pixel-size brush? And even
how meaningful is it? On the other hand, you usually want a 4 or a 5
pixel size brush and it's nearly impossible to get (exactly) by dragging
the scale widget.
It is so annoying that some even resort to edit the value with keyboard!
So I am adding an optional "constrain" feature to GimpSpinScale. It will
still be possible to get fractional values when constraining is on, for
instance with keyboard edit (the arrow incrementation also will keep any
fractional part). So the interaction for such scales is simply reversed
so that you get integers easily, and fractional parts with a bit more
effort.
It is not turned on by default (some feature actually need precision and
we don't want to break the sliders for these) and for the time being, I
only applied it to all the brush settings in paint tools. Now that it
exist, we may want to apply this to more scales in various parts of
GIMP.
(cherry picked from commit bff3903f37)
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
it used to be "text" which is almost always too extreme; use "text_aa"
instead which is half way between "text" and "base" and always gives a
reasonable contrast.
When applying a relative adjustment to a spin scale, don't wrap the
pointer around the corresponding screen edge if the spin scale's
value is already minimal/maximal.
While applying a relative spin scale adjusment (i.e., when dragging
from the lower half of the spin scale), wrap the pointer around the
screen edges (of the current monitor), so that the maximal possible
adjustment amount isn't artifically limited by the screen geometry.
This is especially useful for spin scales in dockables, since
dockables are normally placed near the edge of the screen.
When the mouse is released, move the pointer back to its initial
position (at the beginning of the drag), to allow for subsequent
adjustments.
Unfortunately, moving the pointer programatically isn't supported
on all envrionments (Wayland, Xephyr, ...), and worse yet,
detecting that the pointer failed to move is tricky, so we have to
resort to an ungly hack to maintain the current behavior in this
case. Gah :P
When the mouse hovers over the upper or lower half of a spinscale,
highlight the corresponding area, to hint that the two halves
behave differently. This seems to cause a lot of confusion, so the
different cursors are apparently not enough :P
We use a low-opacity version of the current theme's text color for
the highlight, since it should have a good contrast to both the bar
color and the background color.
More than 2000 lines of code less in app/, instead of
if (instance->member)
{
g_object_unref/g_free/g_whatever (instance->member);
instance->member = NULL;
}
we now simply use
g_clear_object/pointer (&instance->member);
So the adjustment's value is always what is shown (and can be entered
manually) in the widget. This way a GimpSpinScale will never change
its adjustment on focus-out, and not cause whatever unexpected updates
of its model and whatever is connected to it (like changing the
properties and thus unvalidating the caches of a Gegl graph).
which allows to display a value different from the original
adjustment's value.
This is sortof a hack but insanely useful to map normalized config
values to a nicer range (e.g. 0.0 -> 1.0 to 0 ->100).
The default value is 1.0 which is linear and the old behavior, values above
1.0 gives finer control in the lower portions of the range, the lower half of
the widget behaves like before doing small relative adjustments.
- make it respect RTL mode better, something is still weird though
- don't fiddle with the entry's inner_border
- place label and number on the same line
- adjust size_request to respect the label's requisition
- set the label to ellipsize
which allows to restrict the scale to a range that is smaller than
that of the model GtkAdjustment. This way we can enter large values in
the entry or by dragging beyond the end of the scale, but keep a
reasonably usable scale range for "normal" values.
and completely separate configure and sanity checks for gdk-pixbuf
from GTK+, because it's now distributed as a separate package. Remove
all sorts of conditional compiling based on GDK_CHECK_VERSION() and
CAIRO_VERSION.
