It occurs to me that there isn't really that much of a need (if any) for a top down script type config system.

Why isn't ls moving towards xml based config files?

Pros
Clear & consise structure
Easy to standardise (apply to schema)

Other thoughts:

If the ls team didn't want to change the way configs were loaded it wouldn't be hard to put together a tool that stored all the config info in an xml file and output'ed it to a standard rc file. Whenever u need to make a change just use the tool then rewrite the rc file. I'd wager I could even do it if i wasn't so lazy.

The thought of XML configs was tossed around by the devs many a time; however, no dev team so far has lasted long enough to implement it. Each team so far has re-written the core to how they wanted it, and how they thought it would work best, and then promissed XML setups. Now...on your app idea, what would the point be of creating a XML document just so you can convert it back to the old setup? Why not just write the step in the top down format and run with it? (Which btw is already done in at least one app.)

Cons:
harder for humans to read
harder for the program to parse
larger file size
requires lots of new code
requires that code to be debugged

As for your pros:

Clear and concise structure - what structure? If you just want to group a module's settings together, I would much prefer adding a simple block prefix.

Easy to standardize - new modules tend more and more to follow syntax from existing modules. XML only forces standardization that is already possible (and happening), and may hinder any new syntax that needs to be invented.

XML has its uses, config files are rarely among them IMO. (the module descriptions are another matter, that's a much better place to use XML)

the point (DeViLbOi) is that software to configure a module could then be written. In the case of shortcuts.dll you could even put together a tool that would preview the output.

Not that all this cant be done with script files it's just easier when using a structured document format.

RabidCow, I dont see the fact that a new feature requires new code to be a con, its just a fact. new feature = new code! As for readability, well a XML SOAP trans might be pretty hard to read but the bulk of xml files are very easy to read especially if your in ur element with SGML based techs. As for parsability, I can't comment on the specific case of LS not knowing C++ or the LS source, but I can as an enterprise developer say that whipping through an xml file is so damn easy my dog could do it, although my dogs name is Einstein... Next node, grab value, next node grab value.. how is this hard? go read an XML spec.

If you seriously believe that having an applications configuration strewn around in fifty script files (eg: Simplicity) that all include one another at various points is better than a single hierichal config file then... then I have nothing more to say to you!

I'm not sure how many LS users are programmer, but I can say that I'M not, and I'm sure quite a few others aren't as well. now, it may be easy for you to say that looking at xml code is "so *** easy", but that's because you're a programmer. it's what you do. just like I think building my own computer is easy as pie. however, if you ask a NON tech, they would have no idea how to do it. now, I could probably learn XML, but the problem is, the community is trying to make Litestep as user-friendly and accessible as possible, while keeping it highly configurable. I don't think going XML would do that.

Going towards XML does do it because it is easier to write a GUI config...but we already have a GUI config app to write our current script so I don't see the point still.

worldspawn - if we have a GUI config that writes script already, actually I can think of 2, that do it with script I don't see where we gain with XML. As for how Simplicity is configured, nothing says it is right...but many of us agree that multiple include files, one for every module used, is easier to read than the looooooooooong step.rc's of old. if you don't like includes copy and paste everything back in where they are included and get back to the old way of doing things...LS is flexible like that.

New features requiring new code is fine, but what new features do XML bring that justifies the amount of new code it would require? and don't tell me XML is a feature.

Flat text files are trivial to parse, both in terms of computation and in terms of code. You may think moving through a DOM tree is easy, but parsing a flat text file is nothing in comparison. Read a line, pop off tokens. I'm only starting to work with XML, but the learning curve does matter for litestep.

I highly doubt that any theme done as separate files couldn't be done NOW as a single file. There are reasons aside from formatting that make separate files useful, and XML would not change them. (In fact it might add to them because the file is harder to visually scan.) Personally, I use the block folding from scintilla, and that's plenty of structure. (with built-in ToC)

well ok then, lots of schools of thought on the subject.

If the developers were to use a free 3rd party XML parser and interface that with the current internal bindings to the config reading code then surely there wouldnt be that much new code to write?

DeVilbOi : We might already have 1 or 2 config writing tools but if the configs were in a more understandable format then there could be 20 or 30 to choose from.

I don't see how adding a bunch of extra unneeded text to a config helps anything. Flat text files, as stated already, is easier to parse and write than any other config. If modules came with XML docs for all possible settings and explanations, like I am trying to get coded, we could then drop them into config apps and things would be easier. But changing the config to an non-natural layout, such as XML, does not help anyone.

The "extra unneeded text" is what makes the difference between it being flat and structured so it's not all that unneeded.
Second, there would be a herd less parsing to do on an XML file if a 3rd party parser was used.
Thirdly, the modules would only need to come with a list of parameters and the type of value that should be accepted for those parameters (probably in XML format) and a well coded config proggy could take that list and make a dialog box to set all the parameters up for that module.
Lastly ... i would say that the current layout of the config files is not natural as they are so changing to XML wouldnt make a blind bit of difference in that respect.

I don't know what themes you are looking at but my step.rc is very structured and organized.

How can there be less parsing to do if you are going through more text? How are you going to get settings to LS from an external app without doing twice the work?

Having an XML document describing a module is different than configuring LS with it. Having XML docs explain modules to users with doc engines or config tools makes sense and is being worked on.

There is nothing more natural than a setting and its value. Having an xml entry for it that looks like <setting name='PopupTitleText' value='Title'> seems a whole lot more unnatural than "PopupTitleText Title".

Sorry, i was unclear on the first point. I meant structured to a machine as opposed to the human eye.

If the rc was read as a DOM object then it would be a simple case of the code traversing to the correct branch as opposed to manipulating text to come across the values it needs.
By a 3rd party parser i mean a dll parser so litestep rc parsing code invokes the dll parser object and then does its stuff.

Sorry again, you are right on the third point.

Last point, the format really depends on how the developer chooses to implement it. You could have <settings name='PopupTitleText'>Title</settings> or <popup><titleText>Title</titleText</popup> or ... i could go on, there are loads of different formats you could use.
At the end of the day i think i'm coming from a different pov from you.
My aim would be to expand the userbase of litestep and to do that you would need to take a lot of the aggro out of customizing the themes. This would result in very little manual editing of the rc being done and most of it being left to programs to auto generate it and manual editing would only be required for tweaking or whatever. This would also require a few people to code the GUI creators and plugin configuration tools but at the end of the day i think it would be worth it.

By reading this I can see that you don't understand how LS settings are used. They are read in during LS startup and stored in memory locations. For exmaple, you have an array for PopupTitleText with the value of Title. So reading branches of a XML document will just slow you down. Since settings will be stored in memory this way no matter how the config is done, having something structured for the machine doesn't help anywhere.

I still don't understand how user config apps will benefit by writing XML vs. Flat text. I have done a lot of programming with Flat Text files and it is really easy to write "$VariableName$ $VariableValue$".

More to the point, modules want random access to the settings, so a tree structure would be inappropriate. The most natural way to store a .rc file in memory is a hash table. (and I have no idea whether LS actually uses one)

True, i have only browsed over the source. I wasn't aware of exactly how they were stored .. i was focusing on the rc parsing code.
I'm going to conceed on this one. If litestep was an up and coming project with no existing config format of its own then XML would be an excellent choice but since the code has already been written then it might not be worth it.

RabidCow : I assume by random you mean non-sequential access becuase any program reading in it's config parameters in random order is seriously deficient.

As the old saying goes, if it isn't broken then don't fix it. I have nothing against XML, but I can't stand the hype that surrounds it. There is no logic in the idea that everything must be XML. If you have a piece of software like Litestep, that has an existing, working data format then switching to XML is likely a waste of time.

Think about all the work it would take to make LS configuration XML-based. Large parts of the core must be rewritten and debugged. All the config API must be replaced and, consequently, all LS modules must be updated. Everyone has to update their themes. And we must write tools to edit the config files, because XML is not user-friendly.

Then after all that work, you have a system that does nothing more than it already did. Personally, I'd rather spend my time working on real features.

i second maduin's sentiment. this is one of those things that should be saved for a different shell.

Beh, I still don't think XML would be appropriate for configuration, unless there was an explicit tree-like heirarchy of display elements. Config files are intended to be read by one program in one way.