The widget window is usually covered by the bin_window.
Its background color will become relevant when we introduce
kinetic scrolling with overshooting.
_gtk_widget_set_device_window() is suppose to make accounting of
the topmost widget under the device at each time, so avoid setting
it on virtual crossing events as the device is already in another
window.
The implicit grab on priv->event_window already warrants that this
widget is the only one getting events while the button is pressed,
so avoid the extra GTK+ grab here.
This last slave device (stored per master) is used to fill
in the missing slave device in synthesized crossing events
that are not directly caused by a device event (ie due to
configure events or grabs).
Store the device, and unset private fields whenever the device
is shadowed by another GTK+ grab, so popping up menus while
selecting (i.e. press-and-hold) doesn't leave the entry in a
confused state.
* Restores the old padding
* Prelight on spin buttons
* Don't have a generic prelight background selector, as that got
picked up by things like images that should have a transparent bg.
The F keys have no unicode mapping, and UCKeyTranslate() returns
a bogus 0x10 as mapping to unicode. Instead of checking for this
random and undocumented return value, simply assign all function
keys explicitly. This patch also splits the ill-named "known_keys"
array into "modifier_keys" and "function_keys" which is much
more obvious.
(cherry picked from commit 55f9e5cbaf)
Move g_return_if_fail() stuff from the backends to the public
functions in gdkscreen.c itself, and some fixes for ugly formatting in
the various gdkscreen-backend.c files.
No need to subtract focus line width again, since the progressbar is
rendered starting at (0, 0).
This also fixes the entry-progressbar-coloring reftest.
The file "installation" part needed a long-overdue update, especially
as some headers were simply moved into gtk/deprecated and some new headers
were introduced, and a new .gschema.xml file needed to be processed.
Instead of firing a 'quit' signal and expecting the application to do
something that will cause it to quit, just call the new
g_application_quit() API for ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=670485
This seems a bit "too powerful" and unlikely to be used by most
applications. Remove it from now, until someone comes up with a strong
desire for it.
https://bugzilla.gnome.org/show_bug.cgi?id=670485
