Re: My Little Wish List for Gnome
- From: Ian Campbell <ijc25 cam ac uk>
- To: gnome-list gnome org
- Subject: Re: My Little Wish List for Gnome
- Date: Wed, 13 Jan 1999 15:38:28 +0000 (GMT)
hello,
> Hmm, well my opinion is that the menu system shouldn't be tied to the
> filesystem. Create replacement desktop files for each application which say
> that it is now hidden or in the Editors folder. The menu parser will take
> the appropriate action (hopefully :-) ) You won't have more than one
> .desktop file for each menu item (or less if you put everything for the
> user prefs into one humungous file), the same cost as if the user built the
> menu from scratch. This would probably be a big architectural change to
> the Gnome menu stuff but I think it would be worth it..
>
> To make things even simpler, the user's menu entry for Emacs could just
> include the folder it was being moved to and pick the rest up from the system
> entry (so if the system entry changed nothing would be lost) I have
> a thought on how to implement this but no time at the moment..
>
[ snip - my idea - badly explained ;-) ]
> Would you mind repeating this after your exams? :-) I didn't quite follow
> it..
>
I was in a hurry, sorry. But my exam is finished now (it was ok, thanks),
I will try to explain it better now....
your idea is similar to mine, but not quite...
what I was suggesting is that there was no system menu at all (in the
sense of it being a menu), but rather a place where all the system default
.desktop files live. The panel menu can then be generated from the user's
~/.gnome/apps/*.desktop files and not from a combination of the two menus
at all. Each desktop file in the user menu could if desired contain a
defaults= tag which points to the .desktop file in the system menu, other
tags could then overide these settings for that user etc.
The main difference from your idea above is that the .desktop file for an
app is in the same place in the ~/.gnome/apps/ tree as where it appears in
the menu (rather than your way, where a file
~/.gnome/apps/applications/emacs.desktop could cause emacs to appear in an
editors submenu which could be confusing)
for example, the system menu might look like this, where each .desktop
file contains the settings for the app in question
${prefix}/share/apps/applications/
/emacs.desktop
/netscape.desktop
/utilities/
/calc.desktop
/xterm.desktop
/system/
/gmenu.desktop
now, the first time someone logs in they get a menu setup automagically in
~/.gnome/apps that is the same structure as above, except each .desktop
file would simply contain something along the lines of (for emacs):
~/.gnome/apps/applications/emacs.desktop:
[Desktop Entry]
default=applications/emacs.desktop
now if a user wants to overide a setting then they edit the file (or gmenu
does) for that app, to something like this (for netscape with a new icon):
~/.gnome/apps/applicatioons/netscape.desktop:
[Desktop Entry]
default=applications/netscape.desktop
Icon=~/my-netscape-icon.png
now if I want to move emacs to an editors folder (this is where our ideas
differ it seems):
I move ~/.gnome/apps/applications/emacs.desktop to
~/.gnome/apps/editors/emacs.desktop and the menu parser can still quite
happily pick up the system defaults (because of the default=... line in
emacs.desktop).
This seems more intuitive than leaving emacs.desktop in applications
directory with a tag saying that is really in the editors menu. Imagine if
you wanted to change the setting on emacs - you would need to remember
that emacs.desktop was in the applications folder, even though emacs
appears under editors in the menu. This is unlikely to be what most people
will expect.
If you still don't see what I mean (I hope you do - it doesn't say much
for my communication skills otherwise!) then after I code something up it
might become clearer (i hope!).
Cheers,
Ian.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]