Skip to main content
Welcome guest. | Register | Login | Post

Easy configuration script editors

7 replies [Last post]
libervisco's picture
Offline
Joined: 2006-05-04

I'm not a coder, but that doesn't prevent me from having ideas whose expansion may require a coders mind. Smiling

As far as I am aware present GUI configuration tools tend to introduce some complex garbage into the configuration files they edit, or create some intermediary files which only create additional complexity on the overall system.

I assume this is because these tools are developed to just, no matter what, allow the user to configure something with a few mouse clicks. It is assumed that this user wont care what these mouse clicks end up doing to the underlying configuration files and so added complexity, garbage and whatnot is tolerated. You probably know what this ends up becoming on scale of a whole distribution such as Ubuntu, SUSE etc. which are filled with GUI tools, but also with daunting configuration scripts, schemes and barely readable configuration files in the system.

So how about a different approach to creating these configuration tools? Instead of only wanting to have the tool configure something, we start caring about not having this tool introduce any additional complexity. How about a GUI tool which is like a bolt-on text editor editing a configuration file directly, but with configuration file words and syntax converted into some easier to understand buttons or so?

For example, a tool for configuring X would be just a bolt-on GUI frontend to /etc/X11/xorg.conf meant to read that specific file and convert its syntax to buttons, check boxes, drop down boxes etc. So for example when the user wants to set allowed screen resolutions for X he uses a drop down menu which in turn directly writes properly syntaxed entries to the appropriate place in xorg.conf in a clean readable way.

Note that for every single configuration file we would need a special bolt-on GUI front end. It's much like front ends to command line programs, only these are front ends to configuration text files.

Maybe this direct bolt-on approach to making GUI tools would eliminate the need for adding complexity and unreadability to configuration files and scripts whenever we want to have a GUI.

Anyway, I had to get the idea out of my head. If it sounds silly because I'm missing something or I am stating the obvious or an old idea feel free to say. Smiling

tbuitenh's picture
Offline
Joined: 2005-12-21
What you're saying is that

What you're saying is that the configuration tools should be able to parse the configuration files perfectly, instead of just good enough to read their own output. A first solution would be to use the same parser as the program the configuration file is for, but this is not good enough because then comments will be lost.

I believe the perfect solution is to have two files.
/etc/conf is the usual configuration file.
/etc/conf.form contains an easily human readable description of a form, that is already quite similar to the actual configuration file. For example:

/ input \
keyboard = (*) Qwerty (_) Dvorak *when in doubt, choose Qwerty*

/ user \
username = \(_John Doe_\)
cookies = _[0, 3.5] 2_ *all you can eat*

for a configuration file that looks like:

keyboard = Qwerty
username = (John Doe)
cookies = 2.0

and a tabbed GUI (tabs are "input" and "user") with radiobuttons for the keyboard (with a help balloon on mouseover even!) a text input line for the username, and a numeric input between 0 and 3.5 for the cookies (also with mouseover help).

If the user wants to do advanced configuration, then he edits conf.form and runs
conftool --nogui /etc/conf.form
to update /etc/conf .
For simple configuration adjustments, run
conftool /etc/conf.form
to get the GUI.

I thought of this solution about five years ago, and I'm quite surprised nobody else thought of it and implemented it. Why didn't I implement it then? Because I don't need it Sticking out tongue .

libervisco's picture
Offline
Joined: 2006-05-04
Quote: What you're saying
Quote:

What you're saying is that the configuration tools should be able to parse the configuration files perfectly, instead of just good enough to read their own output. A first solution would be to use the same parser as the program the configuration file is for,

Yep.

Quote:

but this is not good enough because then comments will be lost.

Maybe not necessarily. If we modify the parser to display comments as tooltips (if only one line) or as part of the help tab (if multiple line comments).

Quote:

I believe the perfect solution is to have two files.
/etc/conf is the usual configuration file.
/etc/conf.form contains an easily human readable description of a form, that is already quite similar to the actual configuration file. For example:
(...)

So, the GUI reads conf.form which modifies conf, right? Well that looks like a nice solution as well although requiring the user to run conftool --nogui /etc/conf.form every time they want to edit the configuration file directly may not be as perfect as letting him just edit the file directly in whichever text editor they wish. If they do so, will this setup be disrupted (if they do for example nano /etc/conf)?

I know that what I want might seem a bit pointless, but I feel it really isn't. By making it possible for both the geek and average user to edit the file directly, but only with different kinds of editors (average uses a special GUI editor and geek uses whatever editor he wants to) we get the cleanest easy to use distribution ever. It is cleanest because while featuring easy to use GUIs like Ubuntu, it *also* features clean configuration files for those who wish to edit them. Without extra crud and complexity caused by GUIs, the system may be faster and more powerful than something like Ubuntu would ever be, and that is something even average GUI users who wont ever tinker with configuration files directly, would notice.

It's bottom up simplicity above and below the surface likewise.

Quote:

I thought of this solution about five years ago, and I'm quite surprised nobody else thought of it and implemented it. Why didn't I implement it then? Because I don't need it Sticking out tongue

Hehe. I can understand why someone who is happy with just editing conf files directly wouldn't need this, but it is not just about having people who do or don't need it. It is about the effect which this "best of both worlds" approach has on the overall system, making it clean, efficient and simple all the way, no matter which part of the system you are looking that.

I sometimes hear people who can't stand the crud and complexity of Ubuntu, for example, exactly because Ubuntu is following only a one-way approach (the GUI) way instead of two-way where both simple GUIs and simple underlying system is considered. These people would probably appreciate a system which makes GUIs and underlying system simplicity friends rather than enemies. Smiling

tbuitenh's picture
Offline
Joined: 2005-12-21
It can be made easier by

It can be made easier by creating a --edit option for conftool that does the same as
$EDITOR /etc/conf.form ; conftool --nogui /etc/conf.form
that's similar to what the visudo command does.

Quote:

Maybe not necessarily. If we modify the parser to display comments as tooltips (if only one line) or as part of the help tab (if multiple line comments).

Oops. Sorry for using computer science words. A parser takes text, and translate it into meaningful data structures. Comments are, by definition, meaningless. If you modify the parser to keep the comments, you also have to modify the rest of the original program to handle the comments (even if that "handling" just means ignoring). Think about the number of configuration files and programs reading them, and also consider the inefficiency and the risk of introducing bugs, and you know modifying the parsers in the original programs is out of the question.

OK, so copy the parser code before modifying it, instead of sharing it with the original. That works, but it also doubles the amount of parser maintenance work. Besides, it's probably easier to write a braindead new parser that can understand only files generated by the frontend than it is to adapt the original and fit it into a frontend. That's why frontends don't do that, and the problems you describe exist.

My idea takes a different approach: it uses one common form syntax, which completely ignores the syntax of the configuration files. The two syntaxes can coexist in one file without any problems (quite like C preprocessor commands and C). In other words: use different tools/syntaxes for different jobs.

What's also nice is that there's only one conftool instead of dozens, so a lot of the frontend maintenance work is eliminated. And anyone could learn to understand form syntax, so everyone can adapt or design frontend forms if they want to.

The only reason I can think of why nobody else had the same idea and used it is that the original configuration file syntax will show through in the GUI. But that problem can be worked around by simply not showing anything that is not inside form syntax, and introducing labels. In my example:

/ input \
!keyboard:! keyboard = (*) Qwerty (_) Dvorak *when in doubt, choose Qwerty*

/ user \
!user name:! username = \(_John Doe_\)
!edible stuff:! cookies = _[0, 3.5] 2_ *all you can eat*

It's a bit less elegant, but it will work.

libervisco's picture
Offline
Joined: 2006-05-04
Thanks for the explanation.

Thanks for the explanation. I like your solution very much. It would pretty much allow for a system I described.

So, I can now imagine a system that consists of Arch as a base, installs preconfigured with automated routine tasks and uses conftool GUIs (like in your solution) for all configuration tool editing. Conftool can be used in both command line (to launch editing in a given editor of choice) or as command put in clickable GUI launchers for average users to edit configuration files through a GUI.

So the system is easy to use because it is preconfigured and offers nice GUI tools to configure the system. And it is fast, simple and clean underneath for everyone who want to take a peek and edit to do so. Perfect and I think even perfectly doable!

The rest of the story is just in improving the look and feel, package selections and preconfigured settings choice to best fit the average user. The geek user will not mind all the preconfigurations because he can so easily change them all by getting his hands dirty with the clean system underneath it all. Laughing out loud

Awesome. That's what I'm looking for! Smiling

tbuitenh's picture
Offline
Joined: 2005-12-21
Oh, and of course all of

Oh, and of course all of /etc should be in a version control system by default. It's important to be able to undo whatever you did (you forgot what exactly it was) to your configuration file last month that causes a problem now. And this should be easy, so probably conftool should take care of it.

libervisco's picture
Offline
Joined: 2006-05-04
Good idea. I think

Good idea. Smiling

I think something like that would be very useful not only to average users, but to geeks as well. Not everyone notes all changes or saves backups of all changed configuration files. Sticking out tongue

tbuitenh's picture
Offline
Joined: 2005-12-21
I think very few make

I think very few make configuration backups of every single change. Most will only keep a backup of before the last big change, which means they're in trouble when an earlier big change causes some unexpected problem.

IMHO everyone should use revision control for /etc , not doing so is just asking for trouble. darcs is a good choice for this, because it doesn't need a server, it's easy to use, and it's fast so not annoying.