GNOME panel "menu" applet

[Peter Hawkins <peterhawkins ozemail com au>]

Hi there...

I was wondering what people thought about the necessity for a partial
rewrite of the existing menu applet for the gnome panel...

My current criticisms of the existing menu applet are:
* It's slow. It has a noticeable delay while popping up each submenu (as
it re-reads the menu structure from disk). Caching would be good.
* It's ugly and inflexible.
Why am I forced to have two "about" options? I don't CARE... I want
NONE... but I can't REMOVE them... they're SET IN CODE...
Why do we have this weird "panel" menu - with no less than 6 add xyz
options? (excuse me while I look in bafflement at this menu)
Why do I have to edit my menu with the menu-editor? Why can't I use the
filemanager to do it? A bit like (god-forbid) windows...?
Why do we seperate things into "user" and "system" menus? As far as I,
the user, am concerned, it's my panel, I want to be able to change stuff
as I see fit. Being forced to split things into user and system sucks.

So, why don't we do it something like this:
Simply store a menu as a directory of symlinks. Call it ~/.gnome/menu or
something.  Store other information, such as the associated icon, in the
metadata database, like any other file in the system. This may, of
course, require that we break off functions like logout into seperate
executables, but I'm sure we'll live...
If equivalent functionality to "user"/"system" is desired, one could
make a /usr/share/gnome-menu and transparently superimpose this on the
local gnome menu...
Completely scrap any support for things like "Debian menus" and "DE
menus" and so forth, rather implement them the same as any other type of
menu (directory of symlinks), possibly with some form of auto-convertor.

The "panel" menu could be implemented in two ways. The starting of
applets could be implemented using symlinks, the same as any other type
of program. All the other "add" options could delegated to a small
helper executable which activates the required function somehow (CORBA?)
The properties functions really belong in the control center anyway.

Advantages:
* Menu-editor can be scrapped.
* Everything becomes more flexible.
* It's not much harder than what we have there now (reading .desktop
files).

Do people think this is a good idea?

:-)
Peter