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
Instead of having an input/output GdkWindow, make the widget no-window,
and use a separate input-only window for events, and paint on the parent
window directly.
