... 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.
