Re: Bonobo Menu stuff.

[Jaka Mocnik <jaka mocnik kiss uni-lj si>]

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?

>   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?

>   2. I can't decide whether to ditch GnomeUIInfo or not.  Of course,
>      "ditching" would not mean that I wouldn't provide compatibility
>      routines; it's only a matter of whether or not I use GnomeUIInfo
>      for the structure which represents a menu/toolbar item.  Please
>      see the comments in my api definition for more information about
>      this issue.

I prefer the GnomeUIHandler[Menu|Toolbar]Item structures to GnomeUIInfos
much and would like to see the latter ditched ;), especially since they
would provide for much cleaner implementation of dynamic menus &
toolbars (my gnome_app_insert_*() routines are an ugly hack, especially
since they require all the paths to be translated separately from menu
labels:( ), but:

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.)

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

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.

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

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 ;)

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?

regards,
	jaKa

-- 

w3:    http://pluton.ijs.si/~jaka
email: jaka.mocnik@kiss.uni-lj.si