This makes the behavior identical to other widgets which
handle button presses, and it avoids problems when placing
switches into a windows main toolbar.
https://bugzilla.gnome.org/show_bug.cgi?id=656986
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
It turns out that ATK_DEFINE_TYPE_WITH_CODE() is broken; it
tells GType that the class and instance size for the accessible
type are the same as for its parent type. Which is not true
if your instance struct has members such as 'description' here.
This was causing hard-to-track-down memory corruption, since
description and the GtkAccessible private pointer were sharing
the same memory location.
We were ignoring the focus ring padding, and we were incorrectly setting
handle_x to padding.left, while the draw handler already takes padding
into account while redrawing.
https://bugzilla.gnome.org/show_bug.cgi?id=645134
GtkSwitch was listening for Space/Enter keyreleases itself, instead
of providing an 'activate' action signal, like e.g GtkButton. As a
side-effect, this fixes
https://bugzilla.gnome.org/show_bug.cgi?id=643321
Thomas Wood pointed out that the original MxGtkLightSwitch widget upon
which I based the behaviour of GtkSwitch was not written by him; the
original authors are:
Joshua Lock
Robert Staudinger
Jussi Kukkonen
My apologies to all of them.
The GtkSwitch widget is a simple UI control that has two states: on and
off. Toggling between the states is possible by clicking the widget or
by dragging the handle.
https://bugzilla.gnome.org/show_bug.cgi?id=634987
