Re: Menu-2.0, optimized menu tree, hints
Je 1999/07/02(5)/19:07, Steve Greenland montris sian geniecon skribante:
> [talking about Apps/Editors/Emacsen/..., and continuing about
> the collapsing trees:]
>
> Now consider the GIMP: its menu entry might be
> "Apps/Graphics/Editors/bitmaps". But even if the only installed package
> with a menu entry beginning 'Apps/Graphics...' is the GIMP, it will
> still show up under the 'Graphics' subtree.
Well, not the way I see it: menu will see that
Apps/Graphics only has one entry in it, and think: "Hey, I can
remove the Graphics component". The result will be... that
The Gimp will go from Apps/Graphics/Editors/Gimp to Apps/Editors/Gimp,
being next to Emacs.
The reason why you don't really like this, is that "Editor" probably
isn't a right discription for the Gimp. I'm not too good at english,
but probably "Manipulate", "Paint" are better discriptions.
I think that, if there there is a menu structure
A/B/C and
A/X/C
then, if both the B and X submenus only contain one entry, then
in most cases it should be good to merge the two C entries. That
is basically what happens here. For the minority of cases when
it is not `good' for the two C's to merge, I suppose that we
should re-think the name of at least one of the two C's.
> The benefit of the "collapsing" subtree is that my path to a package may
> get shorter or longer, but it will *never* have a *different* component
> at the same level in the tree. Sometimes it's a->b->c->P, sometimes
> it's a->b->P, sometimes it's a->b->c->d->P, but it is *never* a->x->P.
> My understanding of the hints system is that a->x->P could happen, if
> enough packages with hint 'x' get installed.
That is what you don't seem to get.
This is excactly what is also going to happen with the collapsing trees!
Just consider that the x on all systems previously used by you
was collapsed (removed) because it had only one entry.
Then you will *think* that x doesn't exist -- untill it suddenly
is activated when the x menu does get children.
[about a collapsonly option for hints]
> Does that mean that the hints keywords would become order dependent?
Of cource it does.
> If so, we need to have a recommended order (i.e. a menu structure
> policy...which we have)
That goes without saying. It should then be viewed as an extension
of the $section tag.
Thanks,
joostje
Reply to: