GNOME Bugzilla – Bug 677220
Add support for action groups associated with widgets
Last modified: 2012-09-03 17:19:13 UTC
The current situation with GtkApplication is that we have GActionGroup being implemented by the application and each window. When we place a menu or a submenu using gtk_menu_new_from_model() we resolve action names by following the widget hierarchy to the window (for "win") and from that window up to the application (for "app"). Bug 668013 wants to add a button for popping up a menu. It has an API for GtkMenu* because we may not want to have app/window actions for the items in this menu (for whatever reason). It would be nice if we could associate a named action group directly with the button (or some other widget in the hierarchy between the button and the window). In that case the window would just become a special case -- it would be associated with its own action group, named "win". Just as we follow from menus to their attach-widget, we'd also follow from the window to the application that it is associated with (if it is). This would allow introducing an action group called "foo" (for example) associated with the button. The menu in that button could then contain actions targetted at "foo.x" and "foo.y" as well as "win.a" and "app.b". If we wanted to do this in a totally generic way I'd see something along these lines: GActionContext: - GActionContext? get_parent_action_context() - GActionGroup? get_action_group_by_name(string name); GtkWidget implements GActionContext as do some specific widgets: - for GtkWidget, the parent action context would be the parent widget - for GtkMenu, the parent action context would be the attach widget - for GtkApplicationWindow, the parent action context is the application I'm not exactly sure what the API for adding action groups at a particular context node would be. Maybe it would be part of GtkWidget directly, or perhaps another method on GActionContext. This would of course beg a GSimpleActionContext as an implementation helper... my heart is aflutter. You'd find the action group you are interested in by traversing the tree, checking at each node for your named action group. This would be a rather nice way to get rid of the bit of a private mess we currently have for hooking up the menus to the actions of the app/window...
Created attachment 216025 [details] [review] First pass at action rework This introduces the ability for widgets to define their own action context (ie: introduce new named action groups other than "app" and "win" that will be visible to their child widgets). We introduce GtkActionHelper to manage the common tasks associated with implementing GtkActionable. GAction{Muxer,Observerable,Observer} and GSimpleActionObserver are dropped. Accels are not yet working and Mac OS support is almost certainly broken at this point.
There is now the wip/action-helper in git. Mac OS support is somewhat working (thanks to Will) but accels are still broken.
Some preliminary comments from looking briefly at the branch: - I like the cleanup and code reduction, things look cleaner overall - I haven't seen any api to let widgets introduce their own action groups - unless this is intended to be subclassing-only functionality ? - We need working accelerators back, of course - Running bloatpad under gnome-shell gives a ton of (lt-bloatpad:1469): GLib-GIO-CRITICAL **: g_action_group_has_action: assertion `G_IS_ACTION_GROUP (action_group)' failed
The lack of API for widgets to introduce their own actions was based on our 'scaling back' discussion on IRC: at that time I mentioned that it was intended that only the menubutton would have this API and we could extend it into a general functionality if we felt it would be useful. The criticals are related to the fact that the accels don't work. I need to think about that a bit more...
This has been merged to master a while ago...please reopen if this bug is still useful.