Try harder not to push the scale out of balance by marks. With
this change, the remaining difference in the drawing is down
to asymmetric assets and margins coming out of the theme.
To fully support such asymmetric rendering, we need implement
baseline alignment for scales.
https://bugzilla.gnome.org/show_bug.cgi?id=749650
We don't want scale marks to affect scale sizing and positioning,
so draw them inside the range recangle. This avoids size changes
for marks that don't have labels, at least.
https://bugzilla.gnome.org/show_bug.cgi?id=749650
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
We've recently a number of classes wholly. For these cases,
move the headers and sources to gtk/deprecated/ and adjust
Makefiles and includes accordingly.
Affected classes:
GtkAction
GtkActionGroup
GtkActivatable
GtkIconFactory
GtkImageMenuItem
GtkRadioAction
GtkRecentAction
GtkStock
GtkToggleAction
GtkUIManager
Pointed out in https://bugzilla.gnome.org/show_bug.cgi?id=699016
The fix here is slightly different. We make
_gtk_builder_parser_translate return a const char * instead of
a dup'ed string, and fix up the callers.
Problem pointed out by Stefan Sauer in bug 667598. The solution
here is different from his patch. We always draw marks in increasing
direction, and flip the marks and stop positions to match.
The GtkScaleMark values are gdouble, a simple a-b compare func would fail for
values with the same integer value. This breaks the sorting and causes random
marker label placement.
If the scale has an origin (it will have one by default), GtkRange will
render the two sides before/after the current value with different style
classes, making it possible for themes to use different colors and
properties for the two areas.
This was possible in GTK 2 with style details, but got lost during the
road to 3.0.
https://bugzilla.gnome.org/show_bug.cgi?id=665140
Stop documenting the base class as just a base class for the
H and V specializations, copying the useful descriptions from
those H/V classes to the base class. Do not advise the use of
the H/V classes or refer to them unnecessarily.
This is in preparation for making scale marks styling better.
As a side-effect, TOP and LEFT position are treated the same now,
as well as BOTTOM and RIGHT.
Based on a patch by Bastien Nocera,
https://bugzilla.gnome.org/show_bug.cgi?id=643685
