Re: Bonobo Menu stuff.

[Nat Friedman <nat nat org>]

	Thanks for your comments, Jaka!  It's good to receive
feedback.

Jaka Mocnik <jaka.mocnik@kiss.uni-lj.si> wrote:
> Nat Friedman wrote:
> 
> >     2. The current API for defining and manipulating menu and
> >        toolbar items is inadequate.  So while I'm solving problem #1,
> >        I'd like my new API to address problems people have had with
> >        the current API.
> yes, that would be nice, but is this usable for non-bonobo apps?

	It has to be made clear that Bonobo as it stands is not just
embeddable objects and their containers.  It is also the fundamental
component model that GNOME will be using.

	So yes, this is quite usable for any applications that don't
mind linking against Bonobo and ORBit.

> >   1. Because components will need to manipulate menu items which
> >      they did not create (in order, for example, to add submenu items
> >      to them), there needs to be a standard way of referring to these
> >      items.  My idea is to use a path like "File/Quit"[2].  The path
> >      will be a delimited concatenation of the untranslated menu
> >      labels.
> this seems like a well-established way. used by, I think, both Gtk and
> Gnome. and it's human readable. can you think of a better way?

	Miguel suggests that I use a GList instead of a delimited
string.  I prefer the string.  Maybe Mig can explain why he prefers a
GList?

> a) they do not provide as simple an interface for creating menu and
> toolbar structures: you can't simply define a bunch of arrays and create
> a menubar out of them with a single function call (since subtrees are
> stored in a list, etc.)

	There's no reason I can't store subtrees in a NULL-terminated
array, like GnomeUIInfo does.  Would that solve this problem for you?

	
> b) their use is not appropriate for apps that are not either bonobo
> containers or containees and, last but not least:

	That's not true.  Any application can use this interface.

> c) most gnome apps use GnomeUIInfos. requiring people to change all of
> these for the next version of gnome-libs seems like a big joke.

	I intend to provide conversion routines, so to go from a
GnomeUIInfo tree to a GnomeUIHandlerMenuItem tree, you just do
something like:

	tree = gnome_ui_handler_menu_parse_uiinfo (top_level_uiinfo);

> it would however be nice if the GnomeUIHandler could be used for each
> and every gnome-app using GnomeUIInfos.

	I agree.

> now, the questions:
> 
> 1) how do you intend to, say, remove a menu item: its GtkWidget resides
> in the address space of the container and is, a far as I can see from
> the API, accessible only by the means of traversing Gtk's menu tree,
> following its (translated!) labels (possibly accellabels): the process
> that has to remove it is the top-level container, so the call to
> gnome_ui_handler_menu_remove() gets propagated to the top-level
> uihandler which might have no idea how to translate the parts of the
> path as parts of the menu tree described by this path might have been
> created by the components between the one calling
> gnome_ui_handler_menu_remove() and the top level container. (I hope this
> formulation isn't too unclear ;)

	Your explanation is pretty clear, but the problem you describe
is nonexistant.  The top-level GnomeUIHandler service will keep a hash
table mapping GnomeUIHandlerMenuItem paths to the GtkMenuItem widgets.
This is why paths are important as a unique identifier for menu items.

> 2) I don't really see why the whole path member? shouldn't you just use
> untranslated labels for this and reconstruct paths on the fly as you
> traverse the tree?

	The problem with just keeping the untranslated item label
around is that, given a GnomeUIHandlerMenuItem structure, you would
like to know exactly _where_ in the tree it is.  So for example, if I
have "File/Close" and "Window/Close", then there are two menu items
with the label "Close", but they have different paths.  So the path
uniquely determines which menu item is described by the
GnomeUIHandlerMenuItem.  

	With this in mind, you might want to rethink the question you
asked about removing menu items, since the whole idea was to use paths
to refer to menu items.

Regards,
Nat