1 |
hi folks, this came as a reply when I bounced the initial mail to a |
2 |
friend of mine whom I have been discussing implementation and so on with |
3 |
(quite a while before any discussion on the list) |
4 |
|
5 |
|
6 |
//Spider |
7 |
|
8 |
|
9 |
|
10 |
|
11 |
begin forwarded message: |
12 |
|
13 |
Date: Fri, 30 May 2003 17:02:25 +0200 |
14 |
From: redhog <redhog@×××××××××.net> |
15 |
To: Spider <spider@g.o> |
16 |
Subject: Re: Fw: [gentoo-dev] [PROPOSAL] Menu system for all gentoo |
17 |
wm's. |
18 |
|
19 |
|
20 |
Kan du fwd:a mitt svar kanske? |
21 |
|
22 |
----- |
23 |
Hi! |
24 |
First of all both Debian and Mdk does have such systems. But they are |
25 |
different, with different file-formats. In addition, |
26 |
http://www.freedesktop.org/standards/desktop-entry-spec/desktop-entry-spec.html |
27 |
|
28 |
specifies a third format, which is used by GNOME and KDE at the moment. |
29 |
The system in Debian is quite broken, and the implementation (the hack |
30 |
to convert from their format to the ones of the different |
31 |
window-managers) even more so. Esepecially when it comes to translating |
32 |
and transforming the menu. |
33 |
We at TakeIT/Jamtlinux are currently using Debian (don't hate us for |
34 |
that folks!) for a system for high-schools, and thus translation into |
35 |
our native language, aswell as "dumbing-down" the menu (moving all but |
36 |
the most frequently used apps to a special sub-menu), is very important |
37 |
for our application. As the current Debian hack is so broken, I decided |
38 |
|
39 |
to hack a new implementation of it, in Python. I succeeded with a |
40 |
minimal version (supporting the same input format and output to the |
41 |
GNOME/KDE format) of this in just an eavening (the old hack was written |
42 |
in C, and thus much clumsier than mine), and continued with support for |
43 |
different input sources, like the one specified by freedesktop.org. |
44 |
The program reads a set of menu-sources (files or directory structures) |
45 |
of different formats using input-modules, stores all tanslations find in |
46 |
|
47 |
the input-files and combines them with ones provided in special |
48 |
translation/language-packs, filters the entries using simple |
49 |
python-expressions, transforms them (for example their paths down |
50 |
through the menu-tree) using other such expressions, combines all the |
51 |
entries to a tree, translates them using the stored translations, and |
52 |
finally exports them to one or more destination files/directory |
53 |
structures using output-modules for the different fomats. |
54 |
This hack is totally independent of the Debian distribution as such (it |
55 |
depends only on the Python language), and I wouldn't mind if you |
56 |
included it in your distribution and/or added some more input our output |
57 |
|
58 |
modules. |
59 |
/Egil |
60 |
|
61 |
>Hello Folks! |
62 |
>I have recently been thinking on implementing the menu system for |
63 |
>gentoo, something like what we have in mandrake (I guess it came from |
64 |
>debian). At the moment when a user installs a new app he needs to |
65 |
>figure out what is the name of the binary he needs and then add it to |
66 |
>the menu of his window manager(s). This is done automatically only if |
67 |
>you're installing an app for your desktop (i.e. gnome apps on gnome, |
68 |
>kde apps on kde). The whole idea is make thins process automatic - the |
69 |
>user installs a programm foo, log out back in and sees the menu entry |
70 |
>in all window managers. |
71 |
> |
72 |
>Here is my suggestion on who it should work. |
73 |
>On the system we have a central location for the menu, say /etc/menu.d/ |
74 |
>Here all subfolders represent categories and files - menu entries |
75 |
>respectively. The file contains three entries, something like this: |
76 |
> |
77 |
>Name=MyApp |
78 |
>Command=/usr/bin/myapp |
79 |
>Icon=icon.png |
80 |
> |
81 |
>These entries are created when a pckage is merged by a special domenu |
82 |
>command in a ebuild. E.g. domenu Editors, GVim, gvim |
83 |
>In addition to the categories folder the menu.d/ would contain a folder |
84 |
>"rules", which has the ebuild style files describing how the menus for |
85 |
>each installed wm/de should be generated. It would look like this: |
86 |
> |
87 |
>init_menu() { |
88 |
>#Do all nessecary init. here. Eg. touch the menu file. |
89 |
>} |
90 |
> |
91 |
>start_menu() { |
92 |
>#Wright whatever should be in heading of the menu. |
93 |
>#Especially important for one file menus file fluxbox. |
94 |
>} |
95 |
> |
96 |
>write_entry() { |
97 |
>#Ovious. Here we have ${Cat} ${Name} ${Com} vars defined and set. |
98 |
>} |
99 |
> |
100 |
>end_menu() { |
101 |
>#whatever should be done to finish the menu. |
102 |
>} |
103 |
> |
104 |
>Now the most important step: genrating users menu. First of all a user |
105 |
>should have a choice of whether to use this system or not. If the user |
106 |
>likes it he should add a call to syncmenu (a bash scipt) to the |
107 |
>.bash_profile or whatever file. |
108 |
> |
109 |
>When the syncmenu starts it first of all syncronises the ~/.menu with |
110 |
>/etc/menu.d (It will basically sync everything except the files that |
111 |
>have Custom tag - means edited by user and don't touch). Then this file |
112 |
>sources the files in the /etc/menu.d/rules and calls the functions in |
113 |
>the order: init, start, write (for every entry), end. |
114 |
> |
115 |
>I guess the system is quite flexible and allows to support any wm, |
116 |
>irrespectively of the menu style it uses. However, before starting |
117 |
>woking on it I just wanted to get some feedback on the idea. |
118 |
> |
119 |
>Ok, waiting for your criticism ;) |
120 |
> |
121 |
>-- |
122 |
>Sergey Kuleshov <svyatogor@g.o> |
123 |
>Let the Force be with us! |
124 |
> |
125 |
> |
126 |
>-- |
127 |
>gentoo-dev@g.o mailing list |
128 |
> |
129 |
> |
130 |
> |
131 |
|
132 |
|
133 |
|
134 |
|
135 |
-- |
136 |
begin .signature |
137 |
This is a .signature virus! Please copy me into your .signature! |
138 |
See Microsoft KB Article Q265230 for more information. |
139 |
end |