Re: Gnome panel and configuration system



Antonio Campos wrote:
> 
> Colin Fox wrote:
> 
<snip>
> >
> > Well, actually I think you'll find that it IS a directory structure. I
> > often edit it by hand myself.
> >
> > Take a look in /usr/local/share/gnome/apps . This is where all of mine
> > are (I suppose the RPM release versions and tarball development version
> > go into slightly different directories - The dev versions use local,
> > right?).
> >
> > But as for user editing, I think it's *much* easier to fire up a config
> > panel and select "Screensaver" or whatever than it is to try and figure
> > out which directory it would be in. Especially for a newbie. A UNIX user
> > would know to do something like "find /usr/local -type f -exec grep -li
> > screensaver {} \;" but that's not very obvious to the beginner.
> 
> The first thing is that gnome panel applications should reside on the directory
> of every user (example: /home/whoever/.gnome/apps). The installation of this
> files should be done the first time the user starts a gnome-session. And gnome
> should get the data from the global definition /usr/share/gnome/apps.
> As you can see, with your model, only root can modify /usr/share/gnome/apps,
> because only root has access to that directory.
> I mean, the corret behaviour when you edit the menues is to fire up gmc on the
> correct user directory (/home/whoever/.gnome/apps), that way you don't need to
> use a menu editor... (gmc should do the work).

Actually, *SOME* should reside in the user's personal dir, and the
others should reside in a root-writable shared dir. This allows a site
administrator to maintain a standard set of gnome apps for a particular
machine (regardless of the users), and the users could have their own
USER menu with their own apps in the menu.

This is what Windows NT does, and as much as I hate to say it, this is
one thing that I think microsoft did right.

Unless I'm mistaken, this is also the way the Gnome menus work.

If it worked as you described, then when a new user was created, he'd
get the current "official" menu config for that machine, but no-one else
would (since their dirs are just a copy from the original, instead of
USING the original).

And one last thing - What exactly are you expecting GMC to do for user
configuration? Each menu entry has a number of lines of text. GMC is
just a dir util. It's not a text editor, and also users shouldn't be
required to know which parameters a particular application cares about.
An editor embeds all that knowledge so all a user has to do is select
from a menu of choices.

This is why we have menus and buttons in the first place - the user gets
to see what the available options are and choose from them. If you make
them edit the files themselves, then the users need a lot more
understanding of what goes into each file. Even experts forget things,
and selecting things from a menu saves everyone time.

What exactly are you trying to save by having GMC be the editor? It
takes little or no time to create some kind of config editor for an
application, and from then on it can be touched up if things change.
That will be a little bit of time for the developer, but it will save a
LOT of time for the users. I'd rather save time for the 1000 times I'm
going to use something than the one time I'll spend writing it.

-- 
Colin Fox
cfox@telus.net



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]