Re: Gnome panel menus

[James Henstridge <james daa com au>]

There are a few reasons for choosing this approach.  First of all, by
having separate files for each menu entry, when I install the new GNOME
application gnome-xyz, it just has to install a single file for its menu,
rather than having to edit a menu configuration file.

Also, you may have noticed that if you don't have to restart the panel for
additions and changes to take effect.  Every now and then panel checks if
any .desktop files have been edited, and if so reloads them.

In case you are worried about speed, George is working on that.  So you
will probably find the panel menus will get better (personally, I see no
speed problems, but I haven't tried it on a slow machine).

James Henstridge.

--
Email: james@daa.com.au
WWW:   http://www.daa.com.au/~james/


On Fri, 15 Jan 1999, D. Diederen wrote:

> 
> Hello everybody,
> 
> Perhaps I'm completely stupid, but I don't really understand the need of a
> gazillon of separate files to describe the panel menus ...
> 
> Are you doing that because of the Windows way of doing it ? Every window
> manager I've used for now was using a single file, and I didn't see any
> shortcomings in that approach. The KDE panel, which is using separate .kdelnk
> files, was *very slow* to load in comparison (restarting Window Maker is far
> faster than restarting the KDE panel).
> 
> What about to simply have a structured storage file in
> /whatever/path/panel.conf. The panel would simply try to open
> ~/.gnome/panel.conf and then /whatever/path/panel.conf if it fails. The first
> time the user wants to edit a menu, the global one is copied into its home
> directory and then edited.
> 
> Of course, you couldn't rearrange the menu structure with gmc, but what's the
> matter ? A nice, simple menu editor could easily be written with gtk (pack a
> GtkTree and a GtkCList in a GtkPaned, ala 'regedit', and you're done :). 
> 
> I can provide structured storage parsing/saving code*.
> 
> Cu,
> Damien.