Re: Gnome panel and configuration system

[Antonio Campos <acampos ceronet com>]

Colin Fox wrote:

> 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
>
> --
> To unsubscribe: mail gnome-devel-list-request@gnome.org with "unsubscribe"
> as the Subject.

Well, maybe I have been misunderstood or maybe I have explained things incorrectly.
First thing: linux needs a more user friendly installation system. That is, when I
install a software, a reference to that software should appear in "a
Windows95-start-style button".
At this point, gnome, or kde or whatever should have the global system applications
installed under the start button. It's as simple as linking icons in the start
button and submenues with the directory structure of say: /usr/gnome/apps. (Further
subdivided into graphics, games, etc...)
As you said, this way the system administrator maintains the common applications of
all users with only one installation of the application.
Second thing: The "per user menues". Inside the start button should be the entry
"User applications" (or "User Links", as you prefer) (as is nowadays) that is
linking directly to the directory, say: /home/username/.gnome/apps.
That way the user may install personal links to his favourite applications,
directories, whatever.
Third thing: I insist in that entries inside the start button should be simple
directory entries. Why do I say so? Why don't I want a menu editor?. I'll try to
explain through an example:
A well designed GUI (as gnome is trying to do...) is going to be object oriented
(that why CORBA is there). In the future, I'm expecting gmc to be not only a
directories browser, but a complete object explorer, where the objects are defined
through mime-types.
So say you want to edit the "User applications/Graphics" entry. Then you go the
start button, into the User applications entry, and lastly into the Graphics entry.
Then the panel opens up "the new gmc" into the directory
/home/username/.gnome/apps/Graphics. You then press the right button and the gmc
brings up a pop up menu that let you "add a new application". Election that you
follow, leading you into a dialog that lets you describe the name of the
application, the icon of it, the location, etc... Then a "application.desktop" (or
"application.link") file (with the icon you especified before) is created inside
/home/username/.gnome/apps/Graphics.
The next time you open the start button and go inside "User applications/Graphics"
you will see that the application is included because the menu entry is simply
resembling the directory structure.
Easy (for the user, not so easy for the programmer in the beginning...) No need for
the menu editor. Less code for programmers. The GUI is made of little applications
or components, and GMC should be a good union of these little components.
Another clear advantage:
The user can't remove the global installated programs of the start button, because
they are links into /usr/gnome/apps that has accesses only for root. When the user
tries to change one entry, GMC leads him into /usr/gnome/apps and the user can't
remove those files because he hasn't access to them. This is good, because the start
button allways reflects the global installation of the system (maintained by the
system administrator).
While that with the menu editor the program should check if the entries are global
or local (Bad approach) for letting the user not remove or remove them,
respectively. In my approach, removing the entries or not is only a consecuence of
the permissions of the files.

PD: The user allways have the posibility of adding a menu entry into the panel that
leads him directly into his "User Applications", so he doesn't have to see an
overbloated global system configuration.

PD2: I don't like all the things of Windows 9x, but I have to say that many of the
GUI things are very well done (Uncle Bill spent more money investigating in an
user-friendly operating system that in a well designed one).