Re: My Little Wish List For Gnome

[Daniel Burrows <Daniel_Burrows brown edu>]

On Thu, Jan 14, 1999 at 01:59:20PM +0000, Ian Campbell was heard to say:
> 
> I think you may have converted me.....

  Glad to hear it. :)

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

  Good idea.

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

  Pretty much.  My feeling is that all items should have a location
as a default, though.  Also, I've been thinking about the categories, more
on that later.. :-)

> 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

  Right.

> 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

  Right, unless an item overrides the system global setting.  (for example,
the logout command and menu editor might do this)

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

  Right.  I'm not quite sure about the category, because it could also be
implemented with the following system:

[Internet]
type=menu
Location=/Internet

[Browsers]
type=menu
Location=[Internet]

[Netscape]
type=command
location=[Browsers]/Netscape
command=netscape

  and then to move all browsers to /Web:

[Browsers]
Location=/Web

  I think this could probably be used to generate the same menus as the
category representation and has the advantage of not requiring another
case in the programming.  The semantics would probably be a little different
though; for example, putting show=no in apps.net.browsers.* would be overridable
in individual browser items, while hiding the [Browsers] menu would hide all
browsers unconditionally.  Given that, I guess that categories are better
but I thought I'd throw this idea out anyway.

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

  One idea that I had was to generate a temporary menu structure using
a directory hierarchy and to use that to cache menus on disk, rather than
just throwing the menus out. (although that's not what you're talking
about.:-) )  In terms of reparsing files, it should be possible to check
modification times and sizes to see when something changes rather than
reloading everything.

> other than that I don't have any(more ;-) problems with what you are
> suggesting...
> 
> Now we just need a basic implementation ;-)  
> 

  Hmm.  Now is a Bad Time for me, maybe next month.. :-)


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