Re: GNOME panel "menu" applet

[George <jirka 5z com>]

On Mon, Jul 19, 1999 at 08:32:50PM +1000, Peter Hawkins wrote:
> My current criticisms of the existing menu applet are:
> * It's slow. It has a noticeable delay while popping up each submenu (as

there is caching, all it does is check the files if they have changed since 
the last read, if the panel continually rereads the files something is wrong

another way tospeed it up is to set it not to destroy the menu widgets
themselves and to turn off the icons, however, I even tried it on a 486 and
it was OK as far as I'm concerned

> 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...?

you can, go for it, I don't know if mc will let you directly edit the
.desktop files, but the panel will notice all changes immediately, you can
always edit them with gEdit or something

> 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.

ok, figure out a good nice simple fool proof way to keep the menus in
sync and I'll be glad to merge them

> 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...

what about newly installed programs

> 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...

that was the original idea, but it's turned out to be VERY hard in the end
and I don't want any more magic in the menu code

> 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.

they are implemented like that (a 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?

no

1) storing metadata on symlinks may sound nice but doesn't work completely
with things like NFS (sometimes you get different metadata when watching
directories from different computers)

2) merging menus is very very difficult

3) time can be spent on more important things

George