The application menu code wants to do a popup after a given timeout
while holding. We can implement that by adding a function to
manually break the grab held by the button box.
Freeze+thaw around the hover and pressed property notification on leave
since handlers may want to depend on the pressed state on a hover
transition.
Only mouse button 1 is supposed to activate button controls; other
mouse buttons should do nothing unless there is a context menu.
Checking the click count is important, since double-clicks will
otherwise look like unpaired button presses.
http://bugzilla.gnome.org/show_bug.cgi?id=593504
There's seldom a good justification for connecting to signals on
yourself rather than using the default handler slots in the class.
But in particular using the default handler slots means that
an application can connect to ::button-press-event and get in
before the default handling, to implement a button that does
something on press.
http://bugzilla.gnome.org/show_bug.cgi?id=593503
Add an 'active' property to ShellButtonBox. This allows ShellButtonBox
to be used as a "toggle button". It's up the application to connect
it to the ::activate signal; there's no default handling of this.
(It's seldom that the only time you want to toggle a toggle button
through the user interface, so you need some connection to the backend
data store in any case. Removing the default handling all-together
prevents weird interactions.)
When we have built-in styling for ShellButtonBox the 'active' state
would be one of the elements that would be affect the styling.
http://bugzilla.gnome.org/show_bug.cgi?id=593502
This is a Box subclass which adds several signals useful for implementing
"button like" behavior, such as hover and pressed states, as well as
click activation on release.
