[arch-projects] Debian menu program

Jason Chu jason at archlinux.org
Sat Aug 28 22:09:28 EDT 2004

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.


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-projects/attachments/20040828/2109261e/attachment.pgp>

More information about the arch-projects mailing list