Re: ordering uihander menus

[Martijn van Beers <martijn earthling net>]

On Thu, May 18, 2000 at 07:44:27PM -0400, Nat Friedman wrote:
> 
> Insertion points make sense.  I'm not sure if you want Martijn's
> relative-ordering code in light of Miguel's idea of insertion points

Miguel's idea definitely looks like a nice solution. A few observations:

> Miguel de Icaza <miguel@helixcode.com> writes:
> > Ok, let me explain my solution to what I think Nat told you :-)
> > 
> > Basically, in Bonobo elements in menus and toolbars are named using a
> > path, like this:
> > 
> > 	"File/Open"
> > 
> > This means Menu "File", item "Open".
> > 
> > 	"File/New/Item"
> > 
> > means: Menu File, Submenu New, Item "Item"
> > 
> > 	"File/New/Thingie/Item"
> > 
> > means: Menu File, Submenu New, Submenu Thingie, Item "item".
> > 
> > This also applies to Toolbars.
> > 
> > Now, what we want is a mechanism in Bonobo in which we support merging
> > of two menu structures.  Basically this is used while a container
> > embeds a component: the new items from the component need to be merged
> > into the containers menus.
> > 
> > So if both components provide "File" menus, say the container has
> > "File/Open" and the component has "File/Export", then the result is a
> > "File" menu that contains both "Open" and "Export".
> > 
> > Now, the problem that we are trying to solve is the one in which we
> > have to decide *where* to insert things.  For instance, imagine the
> > container has "File/Open" and "File/Exit".  If we merge "File/Export",
> > we dont want the resulting menu to look like "Open", "Exit", "Export".
> > 
> > We want "Export" to be in between Open and Exit.
> > 
> > To attack this problem, I have suggest the creation of "insertion
> > points", which basically are used like submenus, but do not trigger
> > the creation of the submenu.
> > 
> > The container in the example above would have:
> > 
> > "File/*FileOps", "File/*FileOps/Open", , "File/*FileQuits",
> > "File/*FileQuits/Quit"
> > 
> > And the component instead of having "File/Export", it would have
> > "File/*FileOps/Export", which would render visually what we want.

This works very nicely, but it doesn't make sure the menus get ordered
in the same way when two components are active at the same time,
but not activated in the same order. Not that my solution does, but
I think it is pretty important to try to do this (as much as possible)

Another thing that is a bit problematic is if there's not
/Subdir/ path in the container, but there are several components
that have some /Subdir/Something menu items. What will happen
if the first component (which created the /Subdir/ path) goes
away?