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
2008-11-11 Michael Natterer <mitch@imendio.com>
Bug 553765 – Add orientation API to GtkRange
* gtk/gtkrange.[ch]: implement the GtkOrientable interface. Add
evil code that makes sure that the stepper_detail and slider_detail
set in GtkRangeClass continue to work with the hacked subclasses
below.
* gtk/gtkscale.[ch]: swallow all code from GtkHScale and GtkVScale
and add gtk_scale_new() and gtk_scale_new_with_range() which take
a GtkOrientation argument. Set slider_detail to "Xscale" so above
evil code works.
* gtk/gtkscrollbar.[ch]: add gtk_scrollbar_new() which takes a
GtkOrientation argument. Set stepper_detail to "Xscrollbar" so
above evil code works.
* gtk/gtkhscale.c
* gtk/gtkvscale.c
* gtk/gtkhscrollbar.c
* gtk/gtkvscrollbar.c: remove all code except the constructor and
call gtk_orientable_set_orientation() in init().
* gtk/gtk.symbols: changed accordingly.
svn path=/trunk/; revision=21779
2008-08-12 Michael Natterer <mitch@imendio.com>
* gtk/*.c: consistently chain up using
GTK_FOO_CLASS(parent_class)->bar(instance) instead of
(*GTK_FOO_CLASS(parent_class))->bar(instance).
svn path=/trunk/; revision=21085
2008-08-06 Michael Natterer <mitch@imendio.com>
* gtk/gtkcombobox.c
* gtk/gtkiconview.c
* gtk/gtkrange.c
* gtk/gtkscrolledwindow.c
* gtk/gtktreeview.c: remove CLAMPing from values passed to
gtk_adjustment_set_value() since it does it right now.
svn path=/trunk/; revision=21021
2008-08-02 Matthias Clasen <mclasen@redhat.com>
Bug 429427 – Add "arrow-spacing" style property to GtkRange
* gtk/gtkrange.c: Add an arrow-spacing style property.
Patch by Carlos Garnacho and Christian Dywan
svn path=/trunk/; revision=20939
2008-06-30 Cody Russell <bratsche@gnome.org>
* Practically everything changed.
Change all references of GIMP Toolkit (and variations of it)
to GTK+ Toolkit, showing no mercy at all to our beloved
ancestry. (#540529)
svn path=/trunk/; revision=20709
2007-09-06 13:37:28 Tim Janik <timj@imendio.com>
* gtk/gtkrange.c (gtk_range_adjustment_value_changed): removed code
that forced range repaints upon every motion event, because these tend
to stall other repaints on busy CPUs.
added a timer to still force repaints every once in a while (roughly
5Hz atm) to avoid leaving the user without feedback on the range.
fixes bug #460534.
svn path=/trunk/; revision=18730
