Re: GNOME panel "menu" applet

Peter Hawkins <> 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?

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

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


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]