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
