It's pretty useless to make a menu without actions behind it and people
who are using gtk_menu_shell_bind_model() directly are probably not
interested in doing it the GtkApplicationWindow way (so they won't get
the "app" and "win" groups for free). People are going to need to call
gtk_widget_insert_action_group(), so mention this in the docs to help
them along.
GtkMenuTracker folds a nested structure of sections in a GMenuModel into
a single linear menu, which it expresses to its user by means of 'insert
item at position' and 'remove item at position' callbacks.
The logic for where to insert separators and how to handle action
namespaces is contained within the tracker, removing the need to have
this logic duplicated in the 3 or 4 places that consume GMenuModel.
In comparison with the previous code, the tracker no longer completely
destroys and rebuilds menus every time a single change occurs. As a
result, the new gtkmenu testcase now runs in approximately 3 seconds
instead of ~60 before.
https://bugzilla.gnome.org/show_bug.cgi?id=696468
This replaces the previously hardcoded calls to gdk_window_set_user_data,
and also lets us track which windows are a part of a widget. Old code
should continue working as is, but new features that require the
windows may not work perfectly.
We need this for the transparent widget support to work, as we need
to specially mark the windows of child widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
This was broken since commit b2aaa94 in 2008. Its commit message
clearly states that the intention was to check for GTK_GRAB,
GTK_UNGRAB and STATE_CHANGED. Lets do that, then.
This was found by Coverity.
If the display server or GDK hides the window - fire the "deactivate" signal
to ensure that the internal state is consistent.
This patch also ensures that the "deactivate" signal will not be fired for a
menu that is not active.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=670881
gtk_menu_shell_insert() is a virtual function that was being directly
invoked from the class vtable.
Turn it into a proper signal and emit it in the usual way.
https://bugzilla.gnome.org/show_bug.cgi?id=656565
With the demise of GtkList and GtkTree, it has GtkMenuItem as sole
derived class, and is not really adding any value as a separate class.
Its few useful features have been merged into GtkMenuItem.
Bug 629104
The keysyms create a lot of potential namespace conflicts for
C, and are especially problematic for introspection, where we take
constants into the namespace, so GDK_Display conflicts with GdkDisplay.
For C application compatiblity, add gdkkeysyms-compat.h which uses
the old names.
Just one user in GTK+ continues to use gdkkeysyms-compat.h, which is
the gtkimcontextsimple.c, since porting that requires porting more
custom Perl code.
The GtkSubmenuDirection and GtkSubmenuPlacement enumerations
have been deprecated as public API for a while, but are still used
internally in the menu code. Move them to a private header. This
also prevents to generation of GObject boilerplate for these enums.
Allow windows to be dragged by clicking on empty areas in menubars
and toolbars. This is under theme control, via the GtkWidget::window-dragging
style property. The idea is that it makes sense to turn this on if a
theme makes the window frame and the menubar/toolbar appear visually
contiguous.
The main patch was written by Cody Russell, with a contribution by
Ayan George. See bug 611313.
With this change, key events continue to go to an open menu even
when the pointer is moved over a non-selectable menuitem. The mnemonics
are shown and hidden accordingly.
