Re: My Little Wish List for Gnome

[Daniel Burrows <Daniel_Burrows brown edu>]

  I think that given the number of ideas floating around here I should clearly
define what I'm talking about.  So here goes.
My menu parser would work as follows:

  It would view the menus as a collection of menu items.  Menu items would be
self-contained definitions written using some syntax (such as the one
proposed by Quantum Seep or the XMLized version).  Each menu item
could be a menu or a command (with possibly more nifty types like CORBA
objects--thanks Quantum!)  Multiple menu items could be included in the
same file if desired.  Each menu item would have at least
the following associated data:

  For menus and commands, the location (relative to the root of the menu)
where this item appears, ie /Internet.  The location of commands must be
specified by a single parent menu, with the parent menu being either / or
a menu defined at some point in a menu item entry.  ( I think that defining
menus before using them could be made optional, and probably should)

  For commands, the command to run when the item is selected.
  Also for commands, an optional explicit declaration of whether this item
is to be shown or not.
  Also for commands, information on how to test whether this command is present
on the system.

  Probably more information should be included (icons and so on) but this is
a bare minimum.  Menus will only appear if they contain one or more submenus
or commands which appear (ie if I define /Internet/Browsers but don't put
any commands in it, or all the commands are not present, it won't appear)

  When building menus, the menu parser will load files first from a system
repository of menu items, then from ~/.gnome/apps/, examining subdirectories
recursively (the recursive examination isn't necessary).  If an item which has
already been specified is redeclared, any information encountered overrides
the old information.  Probably a clear definition of the order in which
the menu files within a directory are read would be good, but I don't
know what the best thing to do would be.

  One other possibly useful thing would be for local menu items to have their
own directory.

  whew!  Ok, now let's see if I can deal with your objections:

On Wed, Jan 13, 1999 at 05:09:42PM +0000, Ian Campbell was heard to say:
> 
> Hi!
> 
> The main thing I don't like is that your and daniel's system does not have
> the representation of the menu matching the menu as displayed. ie: 
> 
> ${USERDESKTOP}/Browsers/.desktop
>   default=/Internet/Browsers
> 
> where the menu is defined in Browsers, but appears in Internet->Browsers.

  I feel that this indirection is a good thing.  The alternative is to
hardcode locations--which doesn't work too well if you want to move
everything in Applications/ to Programs/ and have to track down every .desktop
file, perhaps including system-wide ones.  You can sort of do this with
a directory tree, but then you run into a problem with user vs system menus,
where some programs are in Applications/ and some are in Programs/.  You
have a solution which I'll get to in a second.

> Also the whole show=no thing bugs me a bit - it just doesn't seem to make
> sense that a file being in ~/.gnome/apps causes that app to _not_ to be on
> the menu. It was for this reason that I first thought of not having the
> system menu affect what appeared at all. 

  I think that it's perfectly ok.  It just changes the attributes of that
menu entry. (some menu entries may be disabled by default so you'd have to
have show=yes)  I agree that it's not entirely intuitive for new users, but
that's what the menu editor is for. :-)

> Of course, in my way - any new items added by sysadmins don't appear
> automatically. I thought about this and as a solution I thought that the
> panel could inform the user a start up about new applications that are
> installed - with the option of adding them to his menu.

  It's an idea.  But this requires scanning the system menu for new entries,
and you have to know which ones were installed before--so to avoid asking the
user about stuff that was already installed, I suspect you'll need something
awfully like show=no (since I think you're suggesting that the files for
items the user deleted will simply be removed).  Also, I think that new programs
should be automatically installed into the menu, or at least have that option
(show=no in the system menu-item collection would make them not appear by
default in my scheme if that was the desired behavior)

> As another solution to this problem I had intended originally that the
> system menu would still appear as a submenu off the bottom of the panel
> menu, allowing users to browse and then right-click to add things to their
> user menu. In the same place that the redhat (or I assume debian) menus
> appear if you have them. This has the added advantage that the user can
> still access the entire system menu if he wants to.

  I see.  Not too bad, but it requires the user to hunt around for new
programs.

  The Debian menu currently replaces the main panel menu, I believe.  I'd
like to see the Gnome menus done the way I suggested (it's close to the Debian
system) and then the Debian stuff converted, actually.. :-) (the Debian menu
system is very nice but it hardcodes the menu names and structure; adding
references to it as Quantum suggested for this would make it an order of
magnitude more flexible..)

> I think that we need to move away from thinking of the system menu as a
> menu and more of a 'repository' with the subdirs representing catagories
> of application available to the user rather than actual folders on the
> menu (is this what debian does?). The user could then choose to include
> certain apps in a menu structure of their own choosing. Apart from default
> settings I don't think the system menu/repository should have any impact
> on what appears on the panel menu or where it appears.

  That's exactly what I was suggesting, but I don't think subdirectories are
indicated.:-)  (and that's sort of what Debian does)  I also think that
the user should be able to modify his or her own menu structure, but I think
that the default structure should be the 'system menu' (also a repository)
and that new programs should appear onto it by default.  Certainly
building the menu from scratch isn't good (although I don't think you were
suggesting that)

  The only real problem with my scheme occurs when a new item appears in a
bad location.  For example, I create a subdirectory called Internet/Mailers and
move my mailers there, then the sysadmin installs a new mailer and it
appears in Internet/.  One way to deal with some of this might be to have
the names optionally include the type of program, eg [mail.Balsa]
and then let the user do something like:
[mail.*]
location=[Internet]/Mailers

  Not sure, though.  I think I'd rather have the new programs automagically
appear than have to manually add them, though, especially if I've installed a
lot of new programs.  (one other option would be to keep a list of what menu
items were known last time we parsed the menu and alert the user when a new menu
item is found)

  Anyway, hope I explained this more coherently than last time.. :-)

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