[arch-projects] Debian menu program
Many people have suggested a universal menu system (one that can keep every WMs menu up to date with all the packages installed on the system). People say that the freedesktop standard will do that for us and all we have to do is wait for WMs to support it. Personally, I think it'll be a while before all the WMs support the freedesktop standard and I'm not sure if we really should wait. Debian had a solution to this problem in the form of its menu program. The menu program consisted of a directory called /usr/share/menu that you stored a menu file in (the menu file describes categories, command names, and titles of programs; each package gets one but can describe multiple programs in a single file), definitions to create menus for each WM, and an update-menus script. The update-menus script would scan all the files in /usr/share/menu and generate menus for all the installed packages. This was done automatically by the dpkg program. My original idea was to port the Debian menu program (version 2) to Arch and add it as an optional service. Someone who has the menu package installed can run update-menus at any time and it would update all the menus for all WMs on the system. The purpose of this system was not to make stupider users but to simplify administration of systems. If I'm a sys admin for a box that has 4 users (let's say it's a family computer) and one user wants me to install freeciv so ge* can play it, do I want to help ger* to add a menu item as well? What if other people in the house want to play freeciv as well? Will I help all of them add these items to their menus? In this way, it simplifies administration, isn't mandatory, and doesn't hide anything. I did a little bit of research into using Debian's menu program, the problem is that depnends on Debian's dpkg. To make this work, someone would have to patch the menu program to work with pacman. Is anyone interested? Jason *ge/gis/ger are the newly proposed third person singular gender-neutral pronouns. Ge is similar to he, gis to his, and ger to him. -- If you understand, things are just as they are. If you do not understand, things are just as they are. My old gpg key expired, the new one is available from keyservers. I was stupid enough not to realize this before it was too late, so I am not able to sign my new key with my old key. If this assurance isn't enough, please contact me.
On Sat, 2004-08-28 at 18:07, Jason Chu wrote:
Many people have suggested a universal menu system (one that can keep every WMs menu up to date with all the packages installed on the system). People say that the freedesktop standard will do that for us and all we have to do is wait for WMs to support it. Personally, I think it'll be a while before all the WMs support the freedesktop standard and I'm not sure if we really should wait.
Well, most of the other freedesktop standards were incorporated very quickly. Everyone uses the official WM hints. KDE and GNOME both support the Desktop and Menu format. There's some other standards that have become popular as well.
Debian had a solution to this problem in the form of its menu program. The menu program consisted of a directory called /usr/share/menu that you stored a menu file in (the menu file describes categories, command names, and titles of programs; each package gets one but can describe multiple programs in a single file), definitions to create menus for each WM, and an update-menus script.
I looked at the format and program, and it all sees too complex and monolithic for the Arch style. Would anyone be opposed to me trying to write one from scratch, to be very simple (but get the job done)? I would rather it be Pacman independent. You'd write a menu file by hand, and then you can just run update-menus from the foo.install script. Doesn't seem to need any more integration than that. I don't have a problem with the actual menu hierarchy though. I see no reason why we can't follow that.
*ge/gis/ger are the newly proposed third person singular gender-neutral pronouns. Ge is similar to he, gis to his, and ger to him.
That's stupid. :) Ben -- I was overjoyed when, having bought a Fujifilm camera, I realized I could justify having /mnt/fuji on my system. -- /.
On Sat, Aug 28, 2004 at 09:30:11PM -0500, Ben Mazer wrote:
On Sat, 2004-08-28 at 18:07, Jason Chu wrote:
Many people have suggested a universal menu system (one that can keep every WMs menu up to date with all the packages installed on the system). People say that the freedesktop standard will do that for us and all we have to do is wait for WMs to support it. Personally, I think it'll be a while before all the WMs support the freedesktop standard and I'm not sure if we really should wait.
Well, most of the other freedesktop standards were incorporated very quickly. Everyone uses the official WM hints. KDE and GNOME both support the Desktop and Menu format. There's some other standards that have become popular as well.
I was refering specifically to the menu standard.
Debian had a solution to this problem in the form of its menu program. The menu program consisted of a directory called /usr/share/menu that you stored a menu file in (the menu file describes categories, command names, and titles of programs; each package gets one but can describe multiple programs in a single file), definitions to create menus for each WM, and an update-menus script.
I looked at the format and program, and it all sees too complex and monolithic for the Arch style. Would anyone be opposed to me trying to write one from scratch, to be very simple (but get the job done)? I would rather it be Pacman independent. You'd write a menu file by hand, and then you can just run update-menus from the foo.install script. Doesn't seem to need any more integration than that.
The problem with writing one from scratch is that you'll run into all the same complaints people had with menu version 1 (some menus have a few items, others too many, etc). That's why I suggested version 2 because it fixes a lot of these problems. Why do something that's does the bare minimum when doing more could be just as easy? I don't remember what actually made it depend on dpkg, we may not need that functionality at all. Adding update-menus to the foo.install script is bad. Then everything will depend on it. That's why I wanted it seperated totally. As I said, I don't remember what was actually needed from dpkg in the first place. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. My old gpg key expired, the new one is available from keyservers. I was stupid enough not to realize this before it was too late, so I am not able to sign my new key with my old key. If this assurance isn't enough, please contact me.
participants (2)
-
Ben Mazer
-
Jason Chu