Bug 94611

#1: KConfigXT provides that info already, in XML format.
#2: There are tons and tested tools for processing our current format, including kreadconfig, kwriteconfig, grep, sed and awk.
#3: See #2
#4: KDE doesn't have a mix of file formats, all KDE applications use KConfig

Note that switching configuration file format brings along great cost for our users.

I agree with you that using buzzwords like XML makes people drool and that it is a great marketing strategy but I don't see technical advantages, perhaps we can offer it as a choice to our users so that we can have all the marketing advantages without actually having to burden our users with the need to use it.

Hi,

In 2002, Tobias wrote a KConfigXMLBackend. Maybe this could be used as a starting point: 

http://lists.kde.org/?l=kde-core-devel&m=101359267519808&w=2

Bye
Christian

1: So why isn't everything using it yet, just drop
kconfig from kde 4.

2: sed grep and awk arn't designed to process the
'current' file format, but they can be hacked to do
so, every time I've ever seen awk,sed and grep used
for configuration processing it's been a hack, and
every time you are 'trying and testing out' your home
breq file format, there great for searching and minor
processing but they don't have the control inplace
that I (or anyone else) should exepct from tools used
to modify system configuration.

kreadconfig and kwriteconfig are better, but again I
can put anything I want into any file I want and not
know that I've done something wrong until I actaully
run the application using the configuration file.


4:
ok/ just picking a few at more-or-less random.

cd .kde/share/apps/kmouth
cat standard.phrasebook
'looks nothing like'
cat wordcompletion1.dict
cd .kde/share/apps/khtml
'which looks nothing like'
cat formcompletions
cd .kde/share/apps/kdesktop
'or anything like'
cat IconPositions


Of those only IconPositions is in the 'standard' kde
format,  and it's also a good example of how structure
has been 'hacked' into the format
e.g.

[IconPosition::my kernel patches]
X=339
X 1024=363
X 1280=339
X 1600=339
X 640=339
X 800=367
Y=138
Y 1024=154
Y 1200=138
Y 480=138
Y 600=138
Y 768=154


the techinical advantage of moving to XML would be.

1: The format would be documented (XSD) I wouldn't
have to guess what the y 600=138 is supposed to mean?

2: XML is resaonably well structured, no need for the
nasty   IconPosition::my kernel patches hack and then
the multiple Y='s

The ability to convert and modify the data with ease
and without specific knowlage of the kdetools.

Potential performance increaes when XML gets build
into the file system level, something that KDE could
neve aspire to with the existing format.


I remeber trying to write some .protocol files and it
was a nightmare trying to find what I should put in
them, I even poked around the code a bit. 
If the files were in XML with XSD I would never have
spent needless amounts of time searching for the
documentation.

Even Microsoft dropped the ini file style format.

It's not about 'buzz' words its about standards, many
companies have seen how XML can help them reduce
complexity, managers generally know it as a good thing
to have and this is because it is defined and a broad
standard, not because they  use <!-- for comments. To
say that the confguratio of the desktop is in XML
format (or any indestry standard) give people more
confidence that it's not just hacked togeter by some
14year old collage kids, or at least if it is they've
though about what there doing.

The only advantage the current format has is that it's
the current format, and even then a lot of people
arn't using it.



		
___________________________________________________________ 
Moving house? Beach bar in Thailand? New Wardrobe? Win 

ok cool,
At the moment it looks like changing the build scripts to allow --enable-xml-configuration and --enable-ini-configuration
which in tern could be used to setup 

"In KConfig the use of KConfigINIBackEnd is hardcoded, so who to make it
dynamic? Someplace there must be decided what BackEnd should be used by
KConfig."

I still think that KConfig's single level restrictions will make formatting clumsy. 
So work needs to be done to either return a configuration structure (node set style) and allow xpath style configuration queries.


anyhow I think the current state of play crates more hastly for users than changing over to nice XML configuration files would. (nice as apposed to
<myapp font_color="value" font_size="value" font_face="value" heading_font_color="value" ......./>)

.kde/share/apps contains data files, config files are stored under .kde/share/config

Ah, sorry.
Anyhow, Arson is putting XML in there already and the
rest of my arguments still hold true.

Maybe there should be a standard to store 'data' in
too, since a lot of it seems to be configuration
anyhow. (If you count icon position and bookmarks as
configuration).


Also.. this would be so much cleaner in XML

[dock_setting_default]
KMdiDock::bottomDock:dockBackTo=mdiAreaCover
KMdiDock::bottomDock:dockBackToPos=8
KMdiDock::bottomDock:geometry=0,0,100,68
KMdiDock::bottomDock:stayButton=false
KMdiDock::bottomDock:tabCaption=Bottom Dock


I've had a better look at KConfigXL and noticed it
isn't the same as KConfig and if everything was moved
to XML KConfigXL would become redundant (or at least
turn into a couple of xsl files).

I don't think the 'hurting' users is a good argument
to prevent change, especially when kde's going 4.0,
look at metrification, I live in the UK and I don't
hear to many kids complaining about the use metric, it
may have been a pain, but standardisation was probably
worth it in the long run. 
Providing a mix of options may be good for a while,
but I wouldn't like to encourage it as it often causes
more problems than it's worth, and the great thing
about OSS is that I can still get kde 1/2/3 (and
probably patch it up a bit) if I require features that
no longer exist.




		
___________________________________________________________ 
Win a castle for NYE with your mates and Yahoo! Messenger 
http://uk.messenger.yahoo.com

Apple uses XML config files, too, and Qt supports them. When we are able to unify KConfig and QSettings, this should be easy to resolve.

Hi,

kdelibs (version 4 and earlier) is no longer maintained since a few years.

KDE Frameworks 5 or 6 might already have implemented this wish.

If not, please re-open against the matching framework if feasible or against the application that shows the issue.

We then can still dispatch it to the right Bugzilla product or component.

Greetings
Christoph Cullmann