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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
