Re: Menu-2.0, optimized menu tree, hints
Je 1999/06/19(6)/13:06, Joey Hess montris sian geniecon skribante:
> joost witteveen wrote:
> > I've just released menu-2.0. It has many new features, one of
> > wich is the automatic optimization of the menu tree, using
> > something I've called "hints". This is what I want to start
> > discussion about with this message.
>
> Wow! You've utterly bypassed the whole policy issue with a brilliant idea!
That's what I thought too... But, as you already notice, there are
drawbacks.
Oh, btw, the reason I haven't loudly warned on debian-policy before
that I was going to do this, and that you didn't need to discuss things,
is that I've been wanting to do this for over one year, and never
got round to doing it.
> > The hints actually work in a rather strange way: when
> > hint_optimize=true (in the config file) then all $section
> > elements (like "section=Apps/Editors", in the menuentry file)
> > are added to the specified $hints variable (new variable in the
> > menuentry file, could be "hints=Bulky,Expert,Serious" for Emacs).
> > The order (/Apps/Editors or /Editors/Apps) of the resulting hints
> > is completely ignored.
>
> So does this mean it gets hints=Apps,Editors,$hints and Apps and Editors are
> two separate hints that are not related anymore?
I'm not sure if I really understand what you say, but yes, Apps and
Editors are not related any more, and menu _could_ make the
section Editors/Apps. This really sounds absurd and wrong,
as clearly "Apps" is the basic thing, and "Editors" is the `child'
of Apps. But wait: menu actually does `feel' this, as it does
notice (that's how the hints procedure works) that there are many
more Apps hints then there are Editors, and, furthermore, that
all menuentries that have hints=Editors, always also have "hints=Apps".
So, in practice, it will never happen that Emacs is put in the
Editors/Apps/Emacs section. Unless of cource there are also
many Games/Editors and System/Editors entries, in wich case
menu might decide to make Editors/System, Editors/Games etc...
And, after getting accustemed to it over the last couple of weeks,
I don't even think this is bad any more. (as long as it's configurable).
> > Although this procedure ignores the real debian tree (so much
> > discussed about), it does eventually come up that look surprisingly
> > like just that tree.
>
> Can you post an example? The thing I'm concerned about is consistency
> accross machines (and across upgrades).
Yes, that is a real problem. That is why the whole thing is configurable,
and even turned off by default. (I didn't want to harvest too many
bugreports while this hints stuff is unknown).
> It sounds like this can generate
> many possible trees that, while optimal, are very different depending on
> what's installed. Which means that a user who is familiar with the menus on
> one system might be completly lost on another.
Well, the trees generated on my computer all very much look like each other.
But you are right, there are diffences.
On the other hand, if we want to prevent that Apps/Editors on one
system has 20 entries, and on my system to only has 2 entries,
then I see no other way out than to re-shape the menu tree.
Whether we make it the default for the users should probably depend
on what people think of the trees generated by menu's hint optimization
routine.
> They'll see some familiar
> menu names, but in different places, and they'll see some unfamiliar items
> as well. For example, they'll be used to going to Apps/Sound for something
> and it'll be Apps/Multimedia on this other system.
Absolutely.
So (as mentioned), it's configurable. One thing I haven't advertised
much yet (isn't even in the docs!), there is the option to forece
the existance (and use) of sertain sections.
For example, if you only have one Apps/Sound entry, menu should
always collaps that Apps/Sound entry (and put RoseGarden or whatever
directly under Apps/). Now, if you don't want menu to do that
to /Apps/Sound, but do like what it does to the rest of the tree,
one can say
forcetree
Apps/Sound
endforcetree
to force the existance (and use) of Apps/Sound.
> But maybe it really works out so this isn't a problem?
Just the way I was thinking.
Maybe it will turn out that for the first-time users, it's best
to use a fixed tree (hints_optimize=false).
But I have recieved quite a number of complaints about the enourmous
number of entries in some sections (usually at places where _my_ tree
is underpopulated), and I do want to be able to give a responce
to those people.
Having said that, I do hope that eventually the `optimized' tree
is good enough also for beginners -- but that just remains to be seen.
--
joostje
Reply to: