PDA

View Full Version : XML Based preference system



Catt
05-11-2002, 01:42 PM
What are the advantages of using this new system?

Not to be negative, however, the disadvantages I have seen so far:

<li> The config file is not as friendly as it was, not as easy to read down through looking for a specific setting with all the 'markup'

<li> Window sizes and positions are not saved


I'm just asking what the trade off is, not passing judgement.

high_jeeves
05-11-2002, 02:23 PM
There are excellent XML editing tools out there if you would prefer to use one... Generally, XML is easier to add properties too, allows for property hierarchies which would be more difficult to acheive in a flat-file..

For example, lets say each window on the screen has the following information:

x, y, width, height, <other stuff>

Create an XML tag called <seq:window>

with the properties above...

now, to define each window you simply do a:

<seq:window id="experience" x="324" y="134" width="134" height="134"/>
<seq:window id="spawnlist" x="324" y="134" width="134" height="134"/>

Instead of:

experience_x = 324
experience_y =132

spawnlist_x = 132
spawnlist_y = 123

it makes data organization easier, and makes parsing much easier (now instead of having to know the names of 50 keys in the file, you only need to know how to parse a "type")...

I havent looked at the XML file for ShowEQ much, but there are the "general" advantages to XML. I use it quite frequently at the office, and find it quite useful for many things (although, I have also seen a few things for which it is ill suited)..

Check out XML.org, they have some good guides to the basics of XML.. (Under resources)

--Jeeves

Catt
05-11-2002, 11:49 PM
OK, I've been looking at this, and so far it's just making my head hurt. Could be a good thing (pain = gain)?

I'd like to see things like Audio Alerts re-enabled, but so far I have not made enough sense out of the XML stuff to be able to do it.

Refugee
05-12-2002, 07:59 AM
I too have noticed that with the XML switch there is now no way to set the Spawn Audio alerts. Can these be re-added?

guice
05-12-2002, 10:33 AM
Create an XML tag called <seq:window>

Would be nice if they did that. ;)

Right now in it's current state it's really basic XML formats. Nothing too advanged.

One think I also noticed is that we have X, Y and Size for Combat Window, Exp window, etc. But not a single one for the Main window. Did I miss it?

If we migrated to the seq:window format tags, it would be easier to read than it is now.
Now, basically it's just the .conf with extra little widgets all over the place.

Ari
05-12-2002, 10:44 AM
Ok good, I'm not nuts and/or blind. I couldn't find the audio alert command stuff either, nor do I see any mention of it in Zaphod's release announcement.

Was this removed intentionally?

high_jeeves
05-12-2002, 01:15 PM
Like I said.. I havnt spent much time looking at the ShowEQ XML file... I guess they have to walk before they run... using XML as a flat file representation tool doesnt buy you much... it really is usefull as a data heirarchy and abstraction language...

--Jeeves

phattie
05-12-2002, 04:52 PM
Its in the seqdef.xml file. Also if you get the new version from cvs today you can change the information from the gui.

I just used pico to edit the seqdef.xml file and used ctrl W to open find and typed in audio and found it no problems. From there It made sense enough to me and I've never seen xml before.

Pigeon
05-13-2002, 05:57 AM
Uggg.... it just looks like a mess to me. While:

<seq:window id="experience" x="324" y="134" width="134" height="134"/>

would be nice, the current system seems to be doing:

<property name="ExperienceWindowXCoor">
<int value="324" />
<comment>Experience Window X Coordinate</comment>
</property>

Rinse, repeat x4

Which doesn't make any intiutive sense to me, and lacks XML's vaunted elegeance which I know nothing about.

Is all of these files gonna get cleaned up, eventually? I can't get around in the current files heh...

high_jeeves
05-13-2002, 08:46 AM
Give the guys some time... I dont know what parser they are currently using (or if they wrote their own), but I'm sure they can and will clean it up.. Also, it looks like Zaphod is pushing to expose everything through the GUI.. that means you wont have to deal with it anyway...

--Jeeves

Zaphod
05-13-2002, 09:30 AM
I haven't responded to this thread up till now because I have been busily working on improving ShowEQ.

The experience window position is saved in the "Experience" section with the rest of the Experience window properties. It looks as follows (those who actually looked as oppossed to typing up random trash should recognize it):



<section name="Experience" >
<property name="WindowPos" >
<point x="320" y="307" />
</property>
<property name="WindowSize" >
<size width="640" height="409" />
</property>
</section>


It has too seperate properties WindowPos and WindowSize.
They are stored seperately because they are used seperately and differently. The WindowPos (positition) is only used if a window is undocked AND the "UseWindowPos" is true in the "Interface" section, whereas the WindowSize (size) is always used. The <point> tag in the "WindowPos" property represents a QPoint that gets past to QWidget::move(). The <size> tag in the "WindowSize" property which represents a QSize that gets past to QWidget::resize().

Using this XML Preference system I could have saved it like this:


<section name="Experience" >
<property name="Window" >
<rect x="320" y="307" width="640" height="409" />
</property>
</section>


I could have done that, but didn't do to the usage, including the fact that for some of the windows (prior to a recent change) their were situations were the size would be saved and NOT the position and vice versa.

Generally the XML format is a basic hierarchy:

<seqpreferences version="1.0">
<section name="Name1">
<!-- Assorted property -->
<property name="property1">
<datatype tag />
<comment></comment>
</property>
<property name="property2">
</property>
</section>
<section name="Name2">
<!-- Assorted properties -->
</section>
</seqpreferences>


Where the <section> breaks tags organize the file into multiple sections used by different aspects of the program, not all of which are simple windows. The <property> tags organize the data by a specific retrievable tag. The <datatype tag> shown above is a stand in for the group of tags used to represent the Qt data types representable in a QVariant. Most of the currently implemented data type tags represent simple data types, plus one non-simple data type, these are (attributes included in square brackets [] are optional):


<string value="" />
<!-- Represents a QString -->
<int value="" [base=""] />
<!-- Represents a signed integer in the optionally specified base>
<uint value="" [base=""] />
<!-- Represents an unsigned integer in the optionally specified base-->
<double value="" />
<!-- Represents a floating point number -->
<bool value="" />
<!-- Represents a boolean (true/false, 1/0) -->
<color [name=""] [red="" green="" blue="" [base=""]] />
<!-- Represents a QColor either by name or by it's RGB value -->
<point x="" y=">
<!-- Represents a QPoint -->
<rect x="" y="" width="" height="">
<!-- Represents a QRect -->
<size width="" height="">
<!-- Represents a QSize -->
<key sequence="" />
<!-- Represents a Qt 3.x QKeySequence /
string usable with Qt 2.x QAccel::stringToKey() -->
<font [family=""] [ponitsize=""] [bold=""] [italic=""] [strikeout=""] />
<!-- Represents a QFont -->
<sizepolicy [hsizetype=""] [vsizetype=""] [horstretch=""] [verstretch=""] />
<!-- Represents a QSizePolicy -->
<cursor shape="" />
<!-- Represents a QCursor -->
<stringlist>
<string value="" />
<!-- Any number of strings -->
<string value="" />
</stringlist>
<!-- Represents a QStringList -->


There are also two complex datatype tags that are not yet implemented (mostly because I hadn't needed them yet):


<list>
<datatype tag />
<!-- Any number and combination of datatype tags -->
<datatype tag />
</list>
<!-- Represents a QValueList<QVariant> -->

<map>
[string value=""] <datatype tag />
<!-- Any number and combination of datatype tags preceded by a string key -->
[string value=""] <datatype tag />
</map>
<!-- Represents a QMap<QString, QVariant> -->


The complex data types <stringlist>, <list>, and <map> are why I have a seperate <property> tag to name and delineate the properties within the sections instead of just throwing a name="propertyName" attribute in on all the datatype tags, since such an attribute would be meaningless in those contexts.

The advantages of this XML based preferences system are:
It makes parsing the configuration file much simpler and less prone to error.
It organizes the data in a uniform way that represents different Qt datatypes, including complex data types that can contain other datatypes, without using 4-50 unrelated entries. So no more:

[Interface]
x = 5
y = 10
width = 640
height = 480
Font = Helvetica
FontSize = 8
FontBold = 0

It allowed for a minimum number of modifications to the existing codes use of preferences. Those who've modifed ShowEQ before probably know why this particular advantage is important (hint: you touched X, and Y seemingly unrelated behavior happens).
It resolves many of the long outstanding issues and bugs that existed in the previous configuration system (Map colors anyone? How about strings with spaces? Heh, how about corrupting comments?).
Supports some level of configuration file data validation.
Is not a binary configuration format (ala Windows registry)
There are a wide variety of fine XML editors available for those who choose to manually edit the files.
It works under both Qt 2.x and Qt 3.x (more difficult to manage then it should be) using Qt's DOM implementation (I could go on a serious rant about that).
It doesn't force all the users to migrate to a new version of Qt (3.x) nor require adding a new compilation requirement (such as a real XML parser like Apache Xerces C++ that is a validating XML parser that supports DTD's, XML namespaces, XML Schemas and provides a reasonable implementation of DOM Level 2).
It was something I was willing to spend the time and write, as opposed to writing yet another brain dead INI file format reader.


Enjoy (or not),
Zaphod (dohpaZ)

P.S. In the time it took to compose this post I could have put in a method of persisting changes to the message dialogs.

Catt
05-13-2002, 12:10 PM
Thank you for the reply and all the info in it, some of the XML is starting to make sense, I'll need to look more at the parsing of it to really get the bigger picture.

I've been working with the audio alerts, which for some reason are not working, I have the update you posted on the 12th, with the audio stuff in the XML, but it still doesn't play the sounds. I have cut/pasted the command to a command line, save the &.amp.; (ignore dots, just for web) and the sound plays. I though it might be the conversion of that so I took it off, still no sound, something is amiss, and I haven't found it yet.

I do very much appreciate the work you and everyone have done on this.

I have been looking at making the maps editable. That is pick this point and move it here, delete this point, insert a new point here, etc. This would much simplify cleaning up maps, but I'm afraid that project is taking some time to get done.

monster69
05-13-2002, 01:40 PM
Right click on the map, goto edit


Have fun!


Monster

high_jeeves
05-13-2002, 03:05 PM
Zaphod,

Thanks for showing your rational for why you have the XML setup the way you do. In my posts I was trying to describe a generic reason why XML is useful when compared to a flat INI file structure. I wasnt trying to describe a "right way" to do it in the SEQ implementation.. I dont have enough knowledge of all of the various things you were trying to solve by switching to XML in order to propose a possible DLD.

I also spend the majority of my work life dealing with XML and Java, which is a whole different animal as compared to XML and C (because of the ability to dynamically reflect on properties and objects)...

I was not trying to critique or bitch about your design of the XML data.. I was simply using SEQ as a common language to discuss the advantages of a XML system in general...

As with everyone else here, we think you do excellent work... if you think people (myself included) are bitching, just ignore us :)

--Jeeves

Catt
05-13-2002, 08:29 PM
Originally posted by monster69
Right click on the map, goto edit


Have fun!


Monster

Not to hijack my own thread... however, what I'm talking about is the ability to change points already put down, not add more, remove the last one.

*warning* ascii 'art'
change from:

...O.....O....
../......./.....
O___O......

to:

...O......O....
...|.......|....
...O____O...

after the map has been saved, reloaded, etc.

Granted, we are talking about aesthetics, but I'm just that way.

edits: ascii art adjustments, aesthetics again :)

Andretta
05-24-2002, 09:53 AM
Is there a Graphic Front-end to the XML config file? I was just wondering. Just when I got the other config file down, it changes :)


Story of my life, day late and a dollar short.

Mr. Suspicious
05-24-2002, 10:10 AM
You shouldn't have to manually edit the showeq.xml file Andretta, just make all changes you want to save to all menus and then save the preferences from inside EQW.

Andretta
05-24-2002, 11:45 AM
I got it, thanks. Not using showEQ anymore, Linux box ded.