Re: Menu-2.0, optimized menu tree, hints

[joost witteveen <joostje@cistron.nl>]

Let me reply once more to this email, as either I don't
understand what is meant with `collapsing trees', or a lot
of other people don't.

Fearing about stuff originally placed in Apps/Vieuwers and Apps/Sound
suddenly being placed in Apps/MultiMedia, Steve wrote:

> I still don't think that I like the idea of the menu tree being
> re-arranged (except the addition and removal of subtrees) just because I
> install a new package. It seems like "collapsible deep trees" would get
> most of the benefit and be a lot less confusing than the hints system,
> cool as it is.

Unless I'm mistaken, this is exctly what happens with collapsing trees
too. So, let me first explain how I think the collapsing trees work:

Before we start making the collapsing trees, we Debian first designs
an expanded tree. As Apps/ already is full, and with the advent of
not just Vieuwers and Sound apps, but also `Feelers', `Smellers'
and `Tasters', we design the tree like

Apps
  Editors
    Text (Emacs, Xedit, etc)
    DTP (dunno, but some will apear)
  Multimedia
    Vieuwers
      Viewonly (imagemagic, xloadimage)
      Edit     (gimp etc)
    Feelers
    Sound
    Smellers
    Tasters
      Biological
      GeneticMod

Well, probalby a much more expanded tree, but you get the picture.
Now, looking closely at this tree, what happens in the early days
of this tree, when the hardware needed for Feelers, Smellers and Tasters
is still way to expensive? Well, probably the Multimedia submenu
is collapsed. So, the tree will look excactly like the tree we have
now. But once the hardware becomes cheeper, hey, suddenly the
Multimedia menu appears. And, it may even be so that on your system
the Vieuwers and Sound submenus are collapsed, so that the result
is just what the people now opposed to hints are fearing:
(collapsed tree possibility:)
Apps
   Editors
     Emacs
     Xedit
   Multimedia
     BigMac
     Gimp
     Display
     SeaSmell

So, the `big' disadvantage people keep coming up with of hints
also is present in the collapsing tree option.

The real difference is that when a program P happens to be in
a/b/c/d/P, then with the hints, that location may be relocated
to a/b/d/c/P (with c and d exchanged). Many probably again really
dislike that, but think about it. The `TreeCollapsers' already
don't mind P appearing a/b/d/P (c being collapsed). Now, if
a user knows "c" should have appeard after a/b/, but sees "d",
then surely the user also knows s/he should open a/b/d/c, to see
program P.

Furthermore, I will probably add an option `onlycollaps' to menu,
that will instruct menu to only collaps the tree, not echange
menu items. So, people still opposed to the exchanging can also
get what they want.

Hints simply are a much more general way to solve the same problem:
  - With the collapsing tree option, while we adopt the new expanded
    tree, we will have a (big) transition perioud where _all_ trees
    generated are crap. (due to packages using a mix of the old and
    newly expanded tree). With hints, during the transition perioud
    we have the option of still using the old tree, that produces
    acceptable, though not perfect, trees.
  - With the expanded tree option, we will also in the future run
    into problems like we do now. It may well be that in the future
    there appear loads more types of Tasters, not just Biological or
    GeneticMod, but many types in between and outside those two. So,
    we'll have to add Apps/Tasters/Eartly/{Bio,Gen,HalfGen,SemiGen}
    and Apps/Tasters/ExtraTer/{?,?,?,?} and Apps/Tasters/Solar/{?,?,?}.
    That transition will mean that all packages under Apps/Tasters
    will have to be adjusted (and by then there will be many such packages).
    With the hints, we'll be able to slowly evolve the tree, and
    avoid transitions where every generated tree is crap.


Thanks,

joostje