Am I the only one who feels that, to a large extent, ease of use *is* a technical problem?
This is a somewhat major proposal and would be a big piece of architecture if implemented. However it's something I've been kicking around in my head for months and I haven't yet come up with a good counter-argument. I'll also be pretty surprised if something similar hasn't been proposed *somewhere* before. I note that on April 20th, the "Gnome System Control Panel Project" was announced (see http://www.gnome.org). I think this is our opportunity to work with its originator, Andy Doran, on making a consistent, easy, and powerful interface for configuring programs. My idea is this: Every program that fetches user-modifiable files to control its behavior (on a Debian system and according to the FHS, these should all be in /etc or as dotfiles/dirs in $HOME) should have a kind an associated interface file. Call it /usr/lib/<package>/gconfig or something. Now bear with me as I'm probably about to abuse some terms from both compiler and object theory. Most configration files are reducible to key/value pairs (sometimes a key word may take multiple values simultaneously, as in a list of pathnames), or a list of grouped key/value pairs (/etc/passwd). To handle this we need to define some primitive object types, like boolean file directory (subtype of file) device (subtype of file) plainfile ... (you get the idea) URI (Universal Resource Indicator, superset of URL's) URL (thus, URL is a subtype of URI) integer string Maybe URI should be a subtype of string...that's a technical decision. I'm painting in broad strokes right now. We must also allow the "interface" file to define its own object types. For instance, /etc/password might do this; it is an aggregation of some of the primitive data types mentioned above. Some common methods should be written into the primitive objects (testing for file not found in the file object, range checking in integer, illegal character detection in string, etc. We must also allow the "interface" file to override methods, and define new ones of its own for existing objects and objects defined within that interface file. The bottom line: For instance, an "interface" file for /etc/X11/xdm/config would work something like this. Be aware that I am no parsing guru and am in no way wedded to the syntactical appearance of this; I'm just trying to communicate the concept. # interface file for /etc/X11/xdm/config defineproperty(boolean(scaled,label("Scaled"),style("yes","no)) definemethod(readscaling,subtype(read)) { # read in line beginning with "catalogue" # for each of the comma-delimited filenames if (right(filename,9) = ":unscaled") fontpath.scaled = false else fontpath.scaled = true } definemethod(writescaling,subtype(write)) { if ! (fontpath.scaled) { fontpath.value = fontpath.value + ":unscaled" } } definetype(fontpath,subtype(directory),addproperty(scaled), \ addmethod(readscaling),addmethod(writescaling)) boolean(clone-self,label("Clone self"),style("on","off")) boolean(use-syslog,label("Use syslog"),style("on","off")) setof(fontpath(catalogue,label("Catalogue")) plainfile(error-file,label("Error file")) integer(default-point-size,label("Default point size")) setof(integer(default-resolutions,label("Default resolutions")) Okay, hopefully some of you will be able to get the gist of what I mean by all of the above. The great thing about this approach is that you can build a data structure understood by gconfig internally, then hand this off to a desired front-end (dumb,ncurses/slang/newt,gtk). Would this be hard as hell to implement? Hell yeah, probably. But think of the potential rewards. Once implemented, initially, package maintainers would have to do the work of developing a thorough understanding of their packages' config files. But once this thing catches on, upstream maintainers may begin to show an interest. Pipe dream, or can we make it real? Or does this suffer from some horrible conceptual flaw that I haven't thought of? I must also say that I am sure I do not have the coding expertise to implement much of this at all. If I did, I'd be on it. -- G. Branden Robinson | Never underestimate the power of human Purdue University | stupidity. [EMAIL PROTECTED] | -- Robert Heinlein http://www.ecn.purdue.edu/~branden/ |
pgpB9vw3vWfBE.pgp
Description: PGP signature
