This allows drawing calendar arrows in all possible states the main widget may
be in.
The arrow_state array is converted into a bit field since it only really needs
to store boolean information about prelight for each arrow.
We add the app-menu and menubar public APIs to GtkApplication while
leaving the implementation in GApplication.
The actual implementation will be moved soon.
Deal with remote action invocations correctly by implementing
GRemoteActionGroup in the same way that GApplication does and pushing
remote activations through the before/after_emit functions of the
GApplication associated with the window.
This is the last part of getting the threading situation right.
https://bugzilla.gnome.org/show_bug.cgi?id=665737
When we have incoming activations or action invocations we should
acquire the GDK lock, just in case the program in question is using gdk
threads.
https://bugzilla.gnome.org/show_bug.cgi?id=665737
When parsing GMenu xml, use the facility for pick up named submenus.
Note that <section id='foo'>...</section> is _not_ a named submenu.
It is a named item with an unnamed submenu :-(
We want accelerators to work, even if the menus are not shown
locally, so we can't rely on the GtkMenu code to set them up
for us. Currently, this code only installs accelerators when the
window is realized.
This allows to specify accelerators in a convenient way, by
adding accel="..." attributes to the menu items in the
XML for the menu.
Currently, the accelerators are extracted only once, when the
menu property is changed on the application.
Move internal accel map API there and update all users.
Also, add an internal function to create an accel path for
an action and parameter, and use it in gtkapplication.c and
gtkmodelmenuitem.c instead of duplicating that code.
