Re: Bonobo Menu stuff.

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

Nat Friedman wrote:
> 
>         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.
ah. understood.

>         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?
I prefer a string too, if it matters ;)

> > 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?
I guess...

> > 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.
yes, I know, I was just thinking of the overhead. that's why said
inappropriate. I guess there is not much of it.

> > it would however be nice if the GnomeUIHandler could be used for each
> > and every gnome-app using GnomeUIInfos.
> 
>         I agree.
so why not, in addition to making the GnomeUIInfo->GnomeUIHandlerItem
conversion routine public, _make_ all apps use GnomeUIInfoHandler by
making the GnomeUIInfo routines just convert the infos to uihandler
trees, and fill in the widget members upon creation. it is a bit memory
abusing, but it won't add much to the total, I suppose. this would be
completely invisible to the apps. and the insert menu routines could be
rewritten to use this. of course, this would mean linking to libgnomeui
implies linking to bonobo and ORBit. is this a problem?

>         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.
rethought ;) the issue is nonexistant.

jaKa

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