Re: My Little Wish List for Gnome

[Daniel Burrows <Daniel_Burrows brown edu>]

On Wed, Jan 13, 1999 at 12:25:04PM +0000, Ian Campbell was heard to say:
> 
> hi,
> 
> I like the basic idea of merging the two menus, but when I consider the
> things a user might want to do, and the complexity of it, I start to think
> there must be a better way. 

  Ok, I can believe that you might be right--but:

> Sure you could have .dektop entries that hide system entries, but if the
> user wants a menu that is radically different to the system menu the whole
> thing becomes a mess: the whole menu is full of .dektops to delete the
> system entries and other entries to put things where the user wants it.
> For example: if I want emacs in a "editors" sub-menu rather than
> "applications" (which is where it is in the current system menu) then I
> (or gmenu) must:
> 
>   - create a .desktop entry to delete emacs from the applications menu
>   - create a .desktop entry to add emacs to the editors menu 
> 
> if a user does this for many things - it's going to get ugly. And if they
> start moving entire sub-folders around? If I want to delete the
> applications menu all together, do I create a applications.desktop in the
> parent folder that has a show=false tag? yuk.. The whole thing seems
> completely unintuitive....

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

> How about a user menu (not merged) where the .desktop entries can contain
> a "defaults=" tag, pointing to the system .desktop entry. The user can
> then move the user menu .desktop around and still be picking up the system
> defaults, or could override them himself. An option in gmenu or on the
> panel (ie the systmem menu still appears as a submenu at the bottom of the
> panel) could be provided to show the user what is in the system defaults
> .desktop files and give them an option to add them to their user menu? 

  Would you mind repeating this after your exams? :-)  I didn't quite follow
it..

> 
> I'm going to code this up after my exams (which start in, ohh, about an
> hour ;-) just to see what it's like.

  Good (retroactive?) luck!

  You may want to take a look at the documentation for Debian's update-menus
program also, it should be online somewhere (or I could mail it to you)

> If everyone thinks my idea is completely naff, that's fair enough, but I
> still think there must be a better way than merging the menus.... thats OK
> as long as users to want to make a radical departure from the way the
> system menus are setup (which it is quite posible that they might).
> 

  I don't quite understand your idea, so I can't really comment on it.. :-)

  For reference, here are some Debian menu files (obviously, they include
info that Gnome doesn't need and leave out info that Gnome needs but hopefully
you'll get the idea)

  For the panel (which appears in my menus under Apps/Misc):
?package(local.gnome):needs="x11" section="Apps/Misc" icon="none" \
  title="Gnome Panel" command="/usr/local/gnome/bin/panel"

  For xteddy (it's more than one program so there are 3 entries):
?package(xteddy):needs=X11 section=Games/Toys\
  title="XTeddy" command="/usr/bin/X11/xteddy"
?package(xteddy):needs=X11 section=Games/Toys\
  title="XPenguin" command="/usr/bin/X11/xpenguin"
?package(xteddy):needs=X11 section=Games/Toys\
  title="Teddy" command="/usr/bin/X11/teddy"

  For xemacs20 (with mule):
?package(xemacs20-mule):  needs=X11  section=Apps/Editors  title="XEmacs20-mule"  command="/usr/bin/xemacs-20.4-mule"

?package(xemacs20-mule):  needs=text  section=Apps/Editors  title="XEmacs20-tty-mule"  command="/usr/bin/xemacs-20.4-mule"

-- 
  Daniel Burrows

  Nothing is hopeless.

  PROOF:
(a) Assume the opposite.
(b) If something _is_ hopeless, then its condition can only improve.
(c) If its condition can only improve, then there must be hope for it.
(d) Therefore, nothing is hopeless.  QED.

PGP signature