In http://mail.gnome.org/archives/gtk-devel-list/2003-August/msg00110.html


Havoc asked:




 - Say I have one GtkPlug inside another GtkPlug inside a toplevel, 


   for example nested Bonobo components.


   So I would imagine each plug and the toplevel have a


   GtkMenuMerge. How does the UI from the innermost plug get


   propagated to the toplevel?


   It seems like the plug in the middle would have to merge in the UI


   from the innermost plug, then propagate the merged XML and actions


   list to the toplevel.


   I don't see API right now to convert GtkMenuMerge into a serialized


   form that could then be merged into another GtkMenuMerge.


   I would expect maybe gtk_menu_merge_get_actions() (gets a 


   flattened view of all actions) and gtk_menu_merge_get_ui() 


   (gets XML representing merged UI). Also, a signal emitted 


   when these change.


 - But another problem: the GtkMenuMerge that does the merge logic


   always creates widgets. So it can only be on a toplevel, not on a


   GtkPlug. Perhaps the merging and the widgeting need to be split


   apart? Or gtk_menu_merge_set_no_widgets()?




The serialization aspect of this has been tackled by adding


gtk_menu_merge_get_ui(). What is missing is 


a) a way to serialize the actions


b) a protocol for sending the serialized actions + ui definition from


plug to socket (plus the necessary logic in the socket to create proxy 
actions)


c) a way to send the verbs of activated proxy actions back from socket to 
plug and have them trigger the original actions 




...and it just occurred to me that the proxy actions need to monitor the 
original actions for state and property changes.