GNOME Bugzilla – Bug 120648
Might need a way to hide and show nodes based on their merge id
Last modified: 2011-02-04 16:12:26 UTC
Sometimes you want to merge and de-merge ui elements often. One example is merging in Cut/Copy/Paste menus when a gtkentry or a gtktextview gets focus. The way gtkmenumerge works means that in order to re-add the ui, the ui xml file must be parsed every time. It might be worth to add functions to show and hide all nodes with a certain menu id. Something like: gtk_menu_merge_hide_nodes (GtkMenuMerge *merge, guint id); gtk_menu_merge_show_nodes (GtkMenuMerge *merge, guint id);
Sounds like a good idea, but we should probably avoid the nodes in the function name, since the nodes are no longer exposed in the API. How about gtk_menu_merge_{hide,show}_ui (GtkMenuMerge *merge, guint id) to parallel gtk_menu_merge_remove_ui (GtkMenuMerge *merge, guint id);
Yeah, sounds good to me.
On the other hand, since actions hold the visible/sensitive state, it might make even more sense to add convenience methods to set the state of all actions in an action group. gtk_action_group_set_visible (GtkActionGroup *group, gboolean visible); gtk_action_group_set_sensitive (GtkActionGroup *group, gboolean sensitive);
I like the notion of group operations. However, we need to be very clear on the semantics to make them comfortable to use. 1) Setting a group property should _not_ change the individual action directly. Bonobo gets this wrong. Specificly it should not be group_set_senstive (bool state) { foreach_action (action_set_senstive (act, state)); } Doing something like that plays havoc with with applications that manage the sensistivity of individual elements. For example in gnumeric we have a paste special operation that is only sometimes allowed. In the implementation outlined above resensitizing the group will enable that action. 2) If (1) is acceptable then the only viable semantic is to limit a GtkAction to only being part of _1_ GtkActionGroup. We could then easily have the sensitivity tests for activation check action and its group. 3) Given (2) Adding per group signals before and after action activation becomes simple too. If this is acceptable I'll work up a patch. -------------------------------------------------------------------------------------- NOTE : I don't think this will quite address all of the issues related to merging. There are several common use cases with different editing modes where we want - the ui elements to remain constant - Non applicable actions to be desensitized - Available actions to change semantics To fall back on gnumeric, this would be like the clipboard actions (acclerators, toolbars) acting on the spreadsheet, or on the edit line depending on which mode you are in. I suspect this sort of thing is best handled at the app level. This is why I'd like to see the Group level signals, it will simplify having the action handlers change their state to multiplex back to the proper modal action.
In my opinion, restricting the group-action relation to be 1-1 and navigatable in both ways (ie give the action access to its group) is reasonable and will make certain things implementable as you already outlined. Use cases involving actions being part of multiple groups can probably be handled by introducing proxy actions. Probably best to ask on gtk-devel-list if anybody has concerns about that though. Didn't you want the before and after activation signals to live on the ui manager ?
ui manager would have been better in that there are likely to be fewer ui mangers than groups, but there aren't that many groups that it's unexceptable
group sensitivity and group visibility are now committed.