On Mon, 27 Mar 2006, sean wrote:
This is not a gui issue, nor is it just an "end user issue". This attitude of "anyone hand editing config files better know what's going on anyways" becomes largely invalid when a standard methodology exists.
I actually don't buy that. You don't change anything when you go to a standard config file format. Anyone editing at the file/gconf/ registry level had better know what the heck they're doing.
I do not see it this cut and dry. There is no line between those people who "know what they are doing" and those who do not.
Everyone else wants a nice GUI that is logically consistent with the problem space they're interested in and provides wizards etc to explain the configuration process.
I am not saying wizards and interfaces that present multiple change values via am interrogated interface is not valuable. I am saying their value is greatly amplified by the needless complexities at the lower layers. I am also saying providing these wizards and interfaces are much more difficult to build pragmatically due to these same complexities.
Projects already exist http://www.libelektra.org/Main_Page for example. The problem is not that code doesn't exist, the problem is one of getting
But gconf and gconf-2 and others existed before the package you cite. Perhaps this one is the end all and be all of config backends. Dunno.
A package designed to take into account other systems can help with the transition, Elektra appears to do this for gconf and I think kde's backend is in the works. I am not saying Elektra is or isn't the solution, only that a solution like it is desirable.