Jamie Guinan wrote:
On Tue, 28 Jan 2003, Steven Paul Lilly wrote:
I'm not a developer and I know nothing about XML and so have no real
opinion as to what the file format should be. I am however woried about
comments like the ones quoted below. The notion that users dont edit
config files by hand may be all fine and good in the microsoft world but
last time I checked I was using linux. You can't make the same
assumptions about what users want to do as you can in the microsoft
world. Most linux users are "power users" and want to have complete
control over everything.
Thus limiting the pool of potential Linux users to the very small number
of "power users".
I never said anything about not allowing GUI config tools. My point is
that you shouldn't mess with a good thing. Make all the GUI tools you
want just don't try and force the use of them.
Opening things up to smooth graphical configurators
makes Linux attractive to more users, and yes, that includes users who
just want their applications to work without wasting time in a text
editor. But I'd rather see Linux become more widely adopted than stagnate
in the backwaters (not that it isn't gaining popularity these days, but it
could do even better).
I hear Apple is using XML for most (all?) of the OSX config files - but
its still FreeBSD underneath, so how does that hurt FreeBSD power users?
If the XML can be kept relativly simple to read and edit then fine but
the end user should never have to use a config tool if they don't want
to. So please keep it as simple as possle. In my opinion the
readability of the config file should be a much bigger concern then
having a multitued of configuration programs out there. Even the best
config program will have it's limits and I for one don't want to be
constrained by them.
I can see 3 ways this can work out:
1) The new format is tolerably readable XML, and power users learn
to see around/through/between the all <>'s.
2) An XF86Config-ish format is used, with an XML layer on top that
some tool boils down to the XF86Config-ish format (I think the
Red Hat printer config tools do something like this). DRI won't
be any the wiser.
3) The inverse of [2], where the DRI format is XML, and a tool
to convert from XF86Config-ish syntax to XML is created, just
to make the power users happy.
number 1 sounds best to me. 3 wouldn't really make me happy.
If you think about it, what *really* matters is the bytes inside DRI.
The XF86Config syntax is just sugar to make it easy to get the right
values in there for people handy a text editor. An XML syntax is just
different kind of sugar which makes it *trivial* to write tools for people
handy with a mouse. Not to mention facilitating features like preventing
invalid configurations from being saved, and other stuff that comes
essentially free with XML.
-Jamie [ crawls back into the woodwork...]
Sincerily,
Steven Lilly
Alan Cox wrote:
XML printed sensibly is ok for human editing (not ideal). Users dont
edit config files however they use apps to do this.
and
Users want config files that work, they expect to use applications to
edit them, and they also expect things like downgrading to work with
the same configuration file - which XML can do.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
