Mouse events that we do not handle should bubble up to the parent
widget, so they can be handled there, instead of disappearing inside
the button. Also use GDK_EVENT_{STOP,PROPAGATE} to make return
values clearer.
https://bugzilla.gnome.org/show_bug.cgi?id=696640
This replaces the previously hardcoded calls to gdk_window_set_user_data,
and also lets us track which windows are a part of a widget. Old code
should continue working as is, but new features that require the
windows may not work perfectly.
We need this for the transparent widget support to work, as we need
to specially mark the windows of child widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
A button is highlighted if the private variable in_button is TRUE.
This variable is set when the pointer is over the button and cleared when
it left the button. When a button is hidden while there is the pointer over
it, GTK generates a leave notification event, in_button is set to FALSE.
But when a button is removed from a container but not destroyed, it is
unrealized and loose its window. It cannot receive the leave notification
event and in_button stay TRUE. So when the button get a new parent it is still
highlighted.
https://bugzilla.gnome.org/show_bug.cgi?id=676890
Touch events don't generate crossing events themselves, so
do not rely on these to determine whether the button release
happened within the event window.
GtkButton currently draws itself as active (pressed down) in case we're
pressing and holding the mouse pointer outside its bounds; this is
misleading though, since we won't activate the button unless the mouse
is released inside the button itself.
Fix this by only setting the ACTIVE state flag when the button is
actually pressed down.
https://bugzilla.gnome.org/show_bug.cgi?id=668141
Setting state flags is actually needed here since this function is called by
GtkButton subclasses which add their specific state flags as a parameter.
This reverts commit e868b8d6ea.
This is the interface for GtkWidgets that can be associated with an
action on a GtkAppicationWindow or associated GtkApplication.
It essentially features 'action-name' and 'action-target' properties
with some associated convenience API.
This interface is implemented by GtkButton and GtkToolButton.
https://bugzilla.gnome.org/show_bug.cgi?id=667394
Since we allocate the standard CSS border to the button now, and center
the child accordingly, there's no need for an additional inner-border
style property. Deprecate it and ignore its values.
https://bugzilla.gnome.org/show_bug.cgi?id=666600
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
This drops the AtkText implementation, and also strips handling
of children out. Instead of listening for enter/leave/press/released,
just listen for state changes on the widget.
Buttons may also be activated at any time from gtk_widget_activate()
or related functions. In that case, just do the 'show the button
as pushed for a short amount of time' trick, but don't actually
try to grab the keyboard device.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This change does not introduce any functionality change, mostly
cosmtic cleanups, like re-linebreak when introduced annotations messed
up indentation or whitespace errors fixes.
