Re: [gentoo-dev] Menu System

[Jon Nelson <jnelson@jamponi.net>]

On 17 Apr 2002 23:22:45 -0500
Tod M Neidt <tod@gentoo.org> wrote:

> On Wed, 2002-04-17 at 23:07, Jon Nelson wrote:
> Hi!
> 
> My post got mangled and was incomplete. I'm appending it whole :)
> > 
> > The problem with that approach is that if you later decide to use
> > gnome, you would have to re-emerge everything to get its menu entry.
> 
> Only if gnome wasn't in the USE.  But that is a good point, if gnome is
> added to the USE later. But then a separate stand alone script could be
> made to parse /var/db/pkg/  and just merge any menu items not present
> that would be with the new USE variable (ok maybe I'm stretching abit :)
> 
> > Having each program place its menu entry (or entries) in a central
> > location (ala Debian, again), and then having a post-process program
> > zip through and create the KDE, GNOME, AfterStep, BlackBox, and
> > so on "system" menus sounds better to me.
> 
> Except from my experience debians menu system becomes a complete mess. 

Can you elaborate on that? I came to Gentoo after many years with
(primarily) Debian at home, and RedHat and others at work. I've not
experienced any kind of issues with the menuing system with Debian,
unlike RedHat (whose menuing system is utterly worthless).

> Having to drill down through multiple submenus to get to what you want. 
> I, personally don't care for that.

That is a detail that doesn't have anything to do with the mechanism, 
but the policy surround the the contents of the entries should be.

> The advantage to this implementation, is that the menu item is inserted
> into the existing submenus categories.

Where the menu is inserted has nothing to do with how or when the 
entries are stored or processed. Only how.

Additionally, your proposed mechanism has the significant disadvantage
of having to know how to process ebuild files, versus just knowing how
to handle menu entries.  Have you ever looked at how Debian handled
their menuing system?  It's a far superior approach than any I've ever
seen before.

Let me say what I want to say using different words:
I feel that Debian has the best *technical* approach to menu systems. 
The contents of the menu entries is somewhat irrelevant at this stage.
Here's how it works:

each program that wants to provide a menu entry, provides a so-called
"menu" file that contains menu entries, in a sort of meta-data format, for
each item it wants in the menu, incl. Categories, etc...

additionally, programs like afterstep, flwm, fvwm, windowmaker, and
environments like gnome and kde, provide so-called menu-interpreter
files, which together with the menu program understand enough of the
menu entries to be able to form their *own* menus, in the *own* format.

The very strong advantage of this mechanism becomes clearer when one
has many window managers, and gnome, kde, or both.  No matter which
WM or environment they choose, the menu entries are the same and are
handled in the 'native' means by their favorite program.

I wrote the menu handling code myself for AfterStep, and it has served
well for several years.

One thing I could always count on with Debain, besides rock-solid
stability, was that the menuing system *worked* and it contained almost
every relevant user-runnable program in a clear, easily understandable
format regardless of which environment or WM I was in.  That can be an
incredible boon to new users, especially those that are used to the 'start
menu' philosophy.

-- 
Pound for pound, the amoeba is the most vicious animal on earth.

Jon Nelson <jnelson@jamponi.net>
C and Python Code Gardener