Gentoo Archives: gentoo-dev

From: Jon Nelson <jnelson@×××××××.net>
To: gentoo-dev@g.o
Cc: tod@g.o
Subject: Re: [gentoo-dev] Menu System
Date: Thu, 18 Apr 2002 11:01:08
Message-Id: 20020418110140.1e399e69.jnelson@jamponi.net
In Reply to: Re: [gentoo-dev] Menu System by Tod M Neidt
1 On 17 Apr 2002 23:22:45 -0500
2 Tod M Neidt <tod@g.o> wrote:
3
4 > On Wed, 2002-04-17 at 23:07, Jon Nelson wrote:
5 > Hi!
6 >
7 > My post got mangled and was incomplete. I'm appending it whole :)
8 > >
9 > > The problem with that approach is that if you later decide to use
10 > > gnome, you would have to re-emerge everything to get its menu entry.
11 >
12 > Only if gnome wasn't in the USE. But that is a good point, if gnome is
13 > added to the USE later. But then a separate stand alone script could be
14 > made to parse /var/db/pkg/ and just merge any menu items not present
15 > that would be with the new USE variable (ok maybe I'm stretching abit :)
16 >
17 > > Having each program place its menu entry (or entries) in a central
18 > > location (ala Debian, again), and then having a post-process program
19 > > zip through and create the KDE, GNOME, AfterStep, BlackBox, and
20 > > so on "system" menus sounds better to me.
21 >
22 > Except from my experience debians menu system becomes a complete mess.
23
24 Can you elaborate on that? I came to Gentoo after many years with
25 (primarily) Debian at home, and RedHat and others at work. I've not
26 experienced any kind of issues with the menuing system with Debian,
27 unlike RedHat (whose menuing system is utterly worthless).
28
29 > Having to drill down through multiple submenus to get to what you want.
30 > I, personally don't care for that.
31
32 That is a detail that doesn't have anything to do with the mechanism,
33 but the policy surround the the contents of the entries should be.
34
35 > The advantage to this implementation, is that the menu item is inserted
36 > into the existing submenus categories.
37
38 Where the menu is inserted has nothing to do with how or when the
39 entries are stored or processed. Only how.
40
41 Additionally, your proposed mechanism has the significant disadvantage
42 of having to know how to process ebuild files, versus just knowing how
43 to handle menu entries. Have you ever looked at how Debian handled
44 their menuing system? It's a far superior approach than any I've ever
45 seen before.
46
47 Let me say what I want to say using different words:
48 I feel that Debian has the best *technical* approach to menu systems.
49 The contents of the menu entries is somewhat irrelevant at this stage.
50 Here's how it works:
51
52 each program that wants to provide a menu entry, provides a so-called
53 "menu" file that contains menu entries, in a sort of meta-data format, for
54 each item it wants in the menu, incl. Categories, etc...
55
56 additionally, programs like afterstep, flwm, fvwm, windowmaker, and
57 environments like gnome and kde, provide so-called menu-interpreter
58 files, which together with the menu program understand enough of the
59 menu entries to be able to form their *own* menus, in the *own* format.
60
61 The very strong advantage of this mechanism becomes clearer when one
62 has many window managers, and gnome, kde, or both. No matter which
63 WM or environment they choose, the menu entries are the same and are
64 handled in the 'native' means by their favorite program.
65
66 I wrote the menu handling code myself for AfterStep, and it has served
67 well for several years.
68
69 One thing I could always count on with Debain, besides rock-solid
70 stability, was that the menuing system *worked* and it contained almost
71 every relevant user-runnable program in a clear, easily understandable
72 format regardless of which environment or WM I was in. That can be an
73 incredible boon to new users, especially those that are used to the 'start
74 menu' philosophy.
75
76 --
77 Pound for pound, the amoeba is the most vicious animal on earth.
78
79 Jon Nelson <jnelson@×××××××.net>
80 C and Python Code Gardener