Re: GNOME panel "menu" applet

[Jacob Berkman <jberkman andrew cmu edu>]

Peter Hawkins <peterhawkins@ozemail.com.au> writes:

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

I believe there is caching.  There is a possibility it is not working
right though.  Look at gnome-core/panel/menu.c and see if you can figure
it out :)

> * It's ugly and inflexible.
> Why am I forced to have two "about" options?

Quite a few people have spent a lot of time working on the panel.  Since
it doesn't have a real menu bar of it's own, the main menu is a fine
place to give credit to the panel's authors.  Also, many more people have
worked on the rest of GNOME, and I figure having one menu item to give
them some credit is definitely due.

> NONE... but I can't REMOVE them... they're SET IN CODE...

I am sure you know how to use C comments, or #if 0...

> Why do we have this weird "panel" menu - with no less than 6 add xyz
> options?

Yes this is bad design.  I am currently rewriting a good deal of the
panel and planned to put the 'add ...' menu items in a sub menu.


> Why do I have to edit my menu with the menu-editor? Why can't I use the
> filemanager to do it?

Better yet, why not be able to completely customize it from the panel?
Remember:

a) many people still use bash as their file manager
b) you can use gmc to edit menus anyway (they are just .desktop files)

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

If you want your system to be single user, you can always chown -R...

> Being forced to split things into user and system sucks.

It doesn't if you are an admin.
 
> So, why don't we do it something like this:

We already have .desktop files... they store this info plus translations.
I believe some time in the near future the .desktop format will change,
perhaps making things a bit better.

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

I don't see why the other add options should be like this.  They are all
internal widgets to the panel and I don't see a reason to make them
external.

> The properties functions really belong in the control center anyway.

Maybe the global one.  control center is not for application properties,
but for system-wide settings.

> Advantages:
> * Menu-editor can be scrapped.

gmenu is actually nice sometimes.  Having two ways of doing something
isn't a bad thing.

Anyway just my thoughts.

Jacob

-- 
"Me fail English?  That's unpossible!" - R. Wiggum