This makes GtkBuilder accept a GMenuMarkup tree at the toplevel
(ie with <menu id='foo'> being a child of <interface>) and the resulting
GMenu object can be obtained via gtk_builder_get_object (builder, "foo").
We need to connect to items-changed on _every_ menu
model, which is somewhat icky. For some reason, this
works fine with a local model, but not with D-Bus in
between. Debugging needed.
We want to avoid handling focus events for the private focus window,
otherwise the keyboard grab taken by for example buttons will cause a
spurious FOCUS_OUT/FOCUS_IN on the toplevel.
The code that did this seems to have been lost in the XI2 transition for
GTK3.
https://bugzilla.gnome.org/show_bug.cgi?id=657578
I expect them to be used a lot, so this approach seems better than
requiring signals that connect to "notify::widget". Also, we can't use
regular functions (like dispose or constructed), becaiuse those assume
that (un)setting of the widget only happens once and with the current
design (a puble set_widget() function) we can't really guarantee that.
Also, I split them into two separate functions as one function is part
of construction and the other part of destruction of the object. And it
doesn't sound like a good idea to have that both be part of one
function.
I wanted to use weak refs to ensure this instead, but it's a performance
problem when used in the treeview and each and every cell adds a weak
ref to the treeview.
The function returns the part of a monitors area that should be
used for positioning popups, menus, etc. The only non-trivial
implementation atm is in the X backend, all the other backends
just return the full monitor area. The X implementation is
currently suboptimal, since it requires roundtrips to collect
the necessary information. It should be changed to monitor
the properties for changes, when XFixes allows to monitor
individual properties.
https://bugzilla.gnome.org/show_bug.cgi?id=641999
Dealing with disabled devices may turn into hierarchy/device
changed events on device IDs with no backing GdkDevice yet,
so protect against that. The device attachment will be handled
correctly when the device is enabled later.
