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 |