Re: My Little Wish List for Gnome

[Daniel Burrows <Daniel_Burrows brown edu>]

On Tue, Jan 12, 1999 at 10:26:57PM +0000, Ian Campbell was heard to say:
> 
> [nb, the user menu is ~/.gnome/apps not ~/.gnome/share/apps ]
> 
> Hello all
> 
> I've been thinking about this for a while. The idea of having separate
> system and user menus doesn't seem very usefull, since the user has no
> control over the contents of the system menu, and so any thing they add
> will be separate to the rest of the tree (ie 2 utilities menus, 2 media
> menus etc), as well as having a system menu full of apps that they might
> not want there.
> 
> I think a better way to allow the user's control over their menu is to
> have the system menu as a sub-menu (similar to the way the redhat menu is
> now) and the user menu as the main menu (I know this used to be
> configurable, but I can't find the option anymore). Items on the system
> menu would then have a right-click option 'add me to the main (user) 
> menu'), and gmenu could allow something similar.  In this way the system
> menu would remain as a list of available applications, and the user can
> choose what he wants on his menu, add his own apps, and structure it how
> he wants. Obviously a default user menu would be setup on the first time
> gnome was started.
> 
> This is just an idea I wanted to put forward for comments, I don't think
> it would be too hard to implement though.
> 
> So what does everyone think?
> 
> Ta,
> Ian
> 

  Is there any reason to have 2 menus?  I haven't delved into the menu system
but I think the best way to handle this would be for Gnome to read menu
entries from both the global directory (<prefix>/share/apps I think) and
the user directory (~/.gnome/apps), then merge the two, so that you end
up with one menu hierarchy containing both sets of menus.  Like in Debian
I have most of the menufiles in /usr/lib/menu, but I can drop extra files
into /etc/menu (and I believe ~/.menu but I haven't bothered with that) and
they get merged into the menu system.

  Probably conflicts should be resolved by the user's setting overriding the
system settings (I might want my Eterms running with --trans --shade even if the
system menu runs them opaquely.)

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