Version: (using KDE KDE 3.3.2) Installed from: Gentoo Packages Hi, Now that the world has aggreed on a set of standards for storing data in a human readable format, parsing that data, transformaing that data and validating it shouldn't kde jump on the band waggon and move all it's configuration files, which are currently in a mix of formants to a XML. This would have a number of benifits. 1: XSD could be used to describe exactly what should go in the configuration files and be used to validate that a file was in the correct format before an application choked on it. 2: There are tons of tried and tested tools for processing XML, develpers and KDE will be able to use thease tools that have been firly well tested to process configuration files, this is as apposed to using whatever format joe blogs decides is good for configuration. 3: It will anable configuration files to easly be converted into another format, for say editing on the web of documentation. 4: It will unify the current mix of file formats reducing the curernt administration nightmare. and finally, It will make KDE the only desktop with standards complient configuration which will help push KDE into the market place. If you tell a company that all the configuraion is in XML format it is something they will be able to grasp and make the product more appealing to them. You could say why change. I'd say why not, it's easier to do it now then have to change in a few years time. You could say that XML is a pain to parse, well so's plain text. There are plenty of tools for modifying XML from the command line (xmlstarlet is my faviorate) and they can reduce you shell scripts down by 50% while allowing the underlieing configuration files to change without causing too many prolems. You could say that XML is slow. Well, it's not hugely slower than text when compaired to a good binary format, how often do you want to read thease configuration files, and in a few years time someone will have written a reiserfs plugin that takes xml and stores it in a highly efficient high perfomance database and KDE will get the benifits without having to change a single line of code. Why XML, why no, after all it's what eveyone else has decided to use.
#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.