Re: My Little Wish List for Gnome

[Ian Campbell <ijc25 cam ac uk>]

I think you may have converted me.....

Basically if you add a global option to your system to not import any of
the system menu stuff... (the magical global show=no) it magically becomes
the same as my way (possibly with some improvements ;-).... someone did
suggest this option earlier but I didn't realize the implications till
just now (oops)...

Just let me clarify what I think you have said (there's been so much
misunderstanding going on ;-)...

As I see it, each item has a unique name (possibly unique within the
namespace of a particular catagory? I think this is better). So at
anywhere under the ~/.gnome/apps I can have a desktop file (or multiple
files, or multiple files with a directory heirarchy of my choice) with the
same name and overide any settings - including location. With the location
being specified by just the parent menu, the location in the menu is
wholely independant of the location of the .desktop file. If an item has
no location then it only appears if a user gives it one.

With the system menu global show=on - all items appear automatically and
you can delete stuff with 'show=no' or move it with
'location=new/location' etc etc

with the system menu global show=off - I get an empty menu and I can
include any menu item anywhere I like with:  
[apps.net.netscape]
location=Net/browsers 
(let's not worry about syntax right now) and ignore all other stuff
without needing show=no

note: apps.net is the _catagory_ of the program - _not_ it's location in
the system (or any other) menu. The catagory could come from a tag within
the definition of the item - rather than the directory structure (which
could follow any organisation the sysadmin/user chooses).

If this indeed what you meant - then I like it, I for one will go along
with it gladly....

I wonder about the performance aspect of it though, mainly the way the
panel currently updates it's menus while it is running... all it needs to
do at the minute is check the directory for that folder each time someone
passes over it. What would be needed now is to periodically reread/parse
all the config files, I assume this could be done quickly/efficiently, so
I think it wouldn't be too much of a problem...

other than that I don't have any(more ;-) problems with what you are
suggesting...

Now we just need a basic implementation ;-)  

Cheers,
Ian

 On Wed, 13 Jan 1999, Daniel Burrows wrote: 

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