Gnome panel and configuration system
- From: Antonio Campos <acampos ceronet com>
- To: "gnome-devel-list gnome org" <gnome-devel-list gnome org>
- Subject: Gnome panel and configuration system
- Date: Sun, 28 Nov 1999 18:41:21 +0100
I was thinking the other day how to minimize some efforts that are being
put in gnome and linux in general, and I came to some ideas I want to share.
Why have a menu editor in the panel? I think the correct way to go is
letting gmc make a lot of the hard work for the applications. I mean
that the menues should be only entries in a directory, and the submenues
or icons only have to be directories or applications links into these
directories (the way Microsoft does it with Windows). So, when an user
wants to add or delete a menu entry, the only thing to need to do is to
edit he directory structure through gmc. If you want to modify the
menues, simply start gmc into the directory that holds the menues
structure (example: .gnome/panel/menues).
That way, the menu editor application simply doesn't need to exist, all
the work is done by gmc.
Another idea for a more "easy linux" (let me know if it is a good or bad
one):
I know this should go to the linuxconf team, but I think this is very
related to gnome.
Why have a linuxconf application, when you can have a directory
structure that holds little controls that modify the computer
configuration?
Let's explain better:
Simply eliminate linuxconf, and add a directory structure (example:
/.gnome/configuration_applets) this way (simply take this like an
example:)
.gnome /configuration_applets:
Network
Users
*users_configurator
TCP/IP
DNS
NIS
SAMBA
Mail Agents
Periphericals
Mouse
*mouse_configurator
Keyboard
*keyboard_configurator
Printers
(Here could go the lists of printers).
*printer_configurator
Joysticks
Screen
ScreenSaver
*ScreenSaver_applet
Themes
*Themes_applet
...
Where * denotes executables (applets or controls with its associated
icons) that when clicked pop up dialogs for configuring things...
Where the identation tries to show up the directory structure.
The list is not complete evidently.
This is way Windows makes a so easy configuration of house systems, and
I think it is a good idea (at least at house computing).
What are we gaining with this kind of configuration? A lot of things:
* The configuration may be made through gmc. No more need of a
control-center. If you want to configure the screen for example, you
simply go to .gnome/configuration_applets/Screen with gmc. Or even
better, configuring the screen right-clicking on the desktop is simply
a matter of starting gmc into the directory
.gnome/configuration_applets/Screen. That way the system gets easier to
maintain, and you can configure things from various points.
* The configuration may be made even through kde or other desktop
manager. As the configuration tools are simply executables, you can also
navigate with kfm to .gnome/configuration and start executing the
configuration controls. That way you homogeneize (??) the configuration
of the system, making it independant from the desktop managers the user
chooses. No more need for a control-center in gnome and another in KDE,
and another in ... (I think I will talk of this in the Linux Standard
Base).
* It's easier to add or remove configuration tools from the system.
Imagine I install sendmail for the mail system. Well, it's easy for the
package subsystem to install a configuration control into let's say
(.gnome/configuration_applets/Network/Mail Agents/SendMail_applet) and
automagically you have a tool for configurating sendmail from GNOME,
KDE, or whatever you want. If you remove sendmail through the package
subsystem, the entire directory
.gnome/configuration_applets/Network/Mail Agents/SendMail_applet
disappears and the configuration tool disappears automatically from all
the system (Nice, I think...).
* The configuration tools are simply executables, so they execute with
the permissions of the owner. So the same executable for configuring the
ScreenSaver may be used for all the users. Even you may add an "apply
this changes to all users" when you execute it like root, and you have
the change made for all users.
* The main issue: the system configuration is homogeneus. No more effort
gets wasted. No more division into the configuration of the system
through KDE and GNOME and linuxconf and ... The executable is unique,
and everyone knows where it is. Even the executable could determine if
the user is using the X-Windows system or a terminal.
* A corollary of that homogeneus system configuration is that you can
simply browse the system configuration through gmc (no need for more
control panels) or even through mozilla (as web pages) when it comes to
the arena. (Simply point the browser into the directory that holds the
configuration components). (this is the way Windows 2000 is going to do
things in the future, I think. And I think is a convient way for its
simplicity. That is something that Linux have to pursuit, at least in
the desktop area).
Well, as you may see, I only say how things should be, but never say I'm
going to do them (Well, If only I knew how to do them :-().
I only try to explain the benefits from such an approach. I think that
could be a nice componentized system configuration. (Microsoft have
something like this, only that without a directory structure; all
components are dropped inside the control panel, although things may
change in the future with the new Windows 2000. We have to be warned...)
After this long e-mail I can only say: thanks for you patience... and
criticism is allways welcome...
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]