GtkRange needs to check if its allocation intersects with the resize
grip allocation (trimming its own allocation if it does).
In order to do that, it needs to translate its allocation into window
coordinates, and before that, find the window to whose the allocation
is relative; code goes all the way finding the right parent widget, but
then doesn't actually use it when translating the coordinates, leading
to using the wrong rectangles for the intersection check.
https://bugzilla.gnome.org/show_bug.cgi?id=662308
This commit introduces a new setting, gtk-visible-focus, backed
by the Gtk/VisibleFocus X setting. Its three values control how
focus rectangles are displayed.
'always' is equivalent to the traditional GTK+ behaviour of always
rendering focus rectangles.
'never' does what it says, and is intended for keyboardless
situations, e.g. tablets.
'automatic' hides focus rectangles initially, until the user
interacts with the keyboard, at which point focus rectangles
become visible.
https://bugzilla.gnome.org/show_bug.cgi?id=649567
Commit 4bb3d64414 introduced a limitation
to GtkRange style properties; when stepper-spacing is > 0,
trough-under-steppers is automatically set to FALSE; this means that
setting a spacing between the steppers (e.g. the scrollbar buttons) and
the trough (i.e. the area over which the slider is free to move) would
make the buttons always get the full allocation on the !orientation
direction.
The rationale is without this limitation, you would get an area which
seems clickable, but it's actually not.
While this is true, and undesirable, for big stepper spacings, themes
that use trough-under-steppers (which is TRUE by default anyway),
might want to set smaller spacings to avoid drawing a double line between
the button and the slider borders.
To add confusion, the documentation got it flipped, i.e. it stated
setting a positive stepper-spacing would set trough-under-steppers to
TRUE (which would also make the behavior expected by commit
4bb3d64414 impossible).
I don't think hardcoding either of the two limitations is a good thing.
We should let themes handle this instead, and remove this limitation. If
you want the old behavior, you can manually set trough-under-steppers to
FALSE if you set a positive stepper-spacing in your theme.
https://bugzilla.gnome.org/show_bug.cgi?id=644777
GtkFileChooserDefault watches the toplevel and montitors "set-focus"
signal on it... however the connection needs to be remade when the
GtkFileChooserDialog is in an embedded toplevel.
Measure's taken: GtkWindow propagates hierarchy changes when
_gtk_window_set_is_toplevel() is called, gtk_widget_unparent()
unsets the widget's parent window earlier in the function so that
the possible hierarchy change is still able to properly access the hierarchy.
GtkFileChooserDefault checks if the "new" toplevel is indeed
gtk_widget_is_toplevel() but not the old one, GtkRange has been
updated to use gtk_widget_is_toplevel() inside it's hierarhcy_changed
vfunc, other classes already do this properly.
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
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
2007-01-16 Matthias Clasen <mclasen@redhat.com>
* gtk/gtkrange.c (range_grab_remove): Queue a redraw when the
grab changes. (#396470, Benjamin Berg)
svn path=/trunk/; revision=17159
2006-11-16 Michael Natterer <mitch@imendio.com>
Add new infrastructure for notifications of failed keyboard
navigation and navigation with restricted set of keys.
The patch handles configurable beeping, navigating the GUI with
cursor keys only (as in phone environments), and configurable
wrap-around. Fixes bugs #322640, #70986, #318827, #334726, #334742
and #309291.
* gtk/gtksettings.c: added properties gtk-keynav-cursor-only,
gtk-keynav-wrap-around and gtk-error-bell.
* gtk/gtkwidget.[ch]: added new signal "keynav-failed" and public
API to emit it. Added New function gtk_widget_error_bell() which
looks at the gtk-error-bell setting and calls gdk_window_beep()
accordingly.
* gtk/gtk.symbols: add the new widget symbols.
* gtk/gtkcellrendereraccel.c
* gtk/gtkimcontextsimple.c
* gtk/gtkmenu.c
* gtk/gtknotebook.c: use gtk_widget_error_bell() or look at the
gtk-error-bell setting instead of calling gdk_display_beep()
unconditionally.
* gtk/gtkcombobox.c
* gtk/gtkentry.c
* gtk/gtkiconview.c
* gtk/gtklabel.c
* gtk/gtkmenushell.c
* gtk/gtkspinbutton.c
* gtk/gtktextview.c
* gtk/gtktreeview.c: call gtk_widget_error_bell() on failed keynav.
* gtk/gtkentry.c
* gtk/gtklabel.c
* gtk/gtkrange.c
* gtk/gtktextview.c: consult gtk_widget_keynav_failed() on failed
cursor navigation and leave the widget if it returns FALSE.
* gtk/gtkmenushell.c
* gtk/gtknotebook.c: only wrap around if gtk-keynav-wrap-around
is TRUE.
* gtk/gtkradiobutton.c: ask gtk_widget_keynav_failed() to decide
whether to to wrap-around, and don't select active items on cursor
navigation if gtk-keynav-cursor-only is TRUE. Should look at
gtk-keynav-wrap-around too, will look into that.
2006-11-15 Michael Natterer <mitch@imendio.com>
* gtk/gtkrange.[ch]: added properties "fill-level",
"show-fill-level" and "restrict-to-fill-level" and getters/setters
for them. The "fill level" is an additional marker on the range's
trough than can be e.g. used to indicate the amount of
pre-buffering in a range showing the play position of streamed
media. See the embedded API docs for details. Made GtkRangeLayout
a GTypeInstance private struct and removed finalize()
implementation. Fixes bug #349808
* gtk/gtk.symbols: added the new symbols.
2006-10-30 Michael Natterer <mitch@imendio.com>
* gtk/gtkrange.c (gtk_range_key_press): consume the Escape key
only if we actually cancel a drag. Fixes bug #58389.
2006-07-18 Michael Natterer <mitch@imendio.com>
* gtk/gtkrange.c: remember the sensitivity of the steppers in
GtkRangeLayout, update it in gtk_range_calc_layout() and check for
changes in layout_changed(), so adjustment changes that leave the
slider position unchanged are still able to update the steppers'
sensitivity. Fixes bug #347902.
2006-06-09 Michael Natterer <mitch@imendio.com>
* gtk/gtkrange.c: added new style properties "trough-side-details"
and "draw-trough-under-steppers" and fixed the "stepper-spacing"
style property. Fixes bugs #342339 and #342249.
"draw-trough-under-steppers", when set to FALSE, starts trough
drawing next to the steppers instead of drawing the trough "below"
(around) the steppers. If "stepper-spacing" is set to any value
larger than zero, "draw-trough-under-steppers" is set to FALSE
automatically to avoid rendering an area that looks clickable but
isn't.
(gtk_range_calc_layout): honor draw-trough-under-steppers.
Don't reserve stepper-spacing on sides of the range that don't
have steppers.
(gtk_range_expose): changed drawing accordingly. Implement
"trough-side-details" which enables drawing of the upper and lower
parts of the trough with different details. This is useful for
theme engines which want to draw these parts differently.
(coord_to_value): correctly take all rendering options into
account. stepper-spacing > 0 caused jumping and otherwise
strangely behaving ranges before.
(other functions): changed accordingly.
2006-05-18 Michael Natterer <mitch@imendio.com>
* gtk/gtkrange.c: canonicalize the name of the "activate-slider"
style property and use GTK_PARAM_READABLE instead of
G_PARAM_READABLE. Moved one "activate_slider" variable to the
local scope its used in.
