We need to be a little more careful when determining the overlap
between the new allocation and the grip area. This was causing
vertical scrollbars in evince to overlap with the grip.
If there are both horizontal and vertical scrollbars, there is
an unused 'corner' into which the resize grip fits. Individual
scrollbars need to be shortened and moved to make room for the
resize grip.
The keysyms create a lot of potential namespace conflicts for
C, and are especially problematic for introspection, where we take
constants into the namespace, so GDK_Display conflicts with GdkDisplay.
For C application compatiblity, add gdkkeysyms-compat.h which uses
the old names.
Just one user in GTK+ continues to use gdkkeysyms-compat.h, which is
the gtkimcontextsimple.c, since porting that requires porting more
custom Perl code.
This was a style property to let theme engines 'opt-in' to more
correct behaviour while maintaining compatibility with existing
themes. GTK+ 3 engines are expected to handle the more correct
behaviour.
This was a style property to let theme engines 'opt-in' to more
correct behaviour while maintaining compatibility with existing
themes. GTK+ 3 engines are expected to handle the more correct
behaviour.
This was a style property to let theme engines 'opt-in' to more
correct behaviour while maintaining compatibility with existing
themes. GTK+ 3 engines are expected to handle the more correct
behaviour.
As usual, this is protected by a style property:
GtkRange::stepper-position-details
The detail strings are
<detail>_start, <detail>_end and <detail>_middle.
See bug 621250
In the early 2.14.x releases, GtkAdjustment was changed to enforce
that values are restricted to the range [lower, upper - page_size].
This has always been the documented behaviour, and the recommended
practice is to set page_size to 0 when using adjustments for simple
scalar values, like in a slider or spin button.
Due to the large number of applications that are affected by this
change, the behaviour has been reverted to the old behaviour in
2.14.3, with an explicit warning that this change will be
reintroduced in 2.90.
This reverts commit e6373738fc.
https://bugzilla.gnome.org/show_bug.cgi?id=619474
* gtk/gtkrange.c: (gtk_range_adjustment_value_change):
Queue the draw also if the range is a scale and the value is drawn,
fixing bug #533946 (Markus Brinkmann), when two HScales use one
adjustment.
This commit was created using a script that searched for all docstrings
containing a parameter and the string 'or %NULL'.
Gdk backends and demos excluded as they are not part of a public API
https://bugzilla.gnome.org/show_bug.cgi?id=610474
Add accessors for range->range_rect, range->slider_range,
range->slider_size_fixed and range->min_slider_size. Didn't add
properties for any of them because thir purpose is mostly to enable
proper subclassing.
2009-02-25 Xan Lopez <xan@gnome.org>
Bug 495320 - GtkRange does not use gdk_event_request_motions
* gtk/gtkrange.c:
(gtk_range_motion_notify): Use gdk_event_request_motions to
request more motion events, as suggested in the docs for widgets
using motion hints.
svn path=/trunk/; revision=22407
2009-01-26 Bastien Nocera <hadess@hadess.net>
Bug 569240 - Crasher when using markers
* gtk/gtkrange.c (gtk_range_destroy): Avoid crashes when destroying
a GtkRange with markers
svn path=/trunk/; revision=22224
Bug 565656 – Add marks to scales
* gtk/gtkrange.[hc]: Add internal api to define 'stop values'
that have a little resistance when dragging the slider over it.
* gtk/gtk.symbols:
* gtk/gtkscale.[hc] (gtk_scale_add_mark): New function to add
a 'mark' to a scale, which will draws a tick, plus optionally
some text, and makes the value a stop value.
(gtk_scale_clear_values): Removes all marks.
* tests/testscale.c: Test for marks on scales
* tests/Makefile.am: Integrate it
svn path=/trunk/; revision=22149
