Warzone 2100 Forums

Curious, regarding this topic.

/lib/framework/wzconfig.h wrote:

Code: Select all

// QSettings is totally the wrong class to use for this, but it is so shiny!
// The amount of hacks needed are escalating. So clearly Something Needs To Be Done.
class WzConfigHack
{
...

What other hacks around the code are related to the use of QSettings there? What is the status of WzConfig class defined like that: is it planned to get re-made soon, or seems fine so far?

No need for a long reply here (:

I've managed to contain all the hacks in wzconfig.h and wzfs.h, and the interface defined there for the rest of the code to use is in my very humble opinion very good.

There is no plan to remake it that I know of. I have been looking at ripping out QSettings from Qt4, changing its interface to match what we need, and putting it in our codebase, but I never went any further with that idea. Perhaps someone could look at what the Trolls have done with QSettings in Qt5...

...and if someone wants to change everything to use QJson (now part of Qt5) instead, I'm not going to stand in the way of that.

I've managed to contain all the hacks in wzconfig.h and wzfs.h, and the interface defined there for the rest of the code to use is in my very humble opinion very good.

Thanks, that's what i wanted to hear. (:

Per, I think that nothing really changed there (at least in terms of API itself)...
http://qt-project.org/doc/qt-5.0/qtcore/qsettings.html
BTW, I don't think that inheriting directly from QSettings is good idea, personally I'm wrapping it (due to gain some additional benefits):
http://paste.org/59899
Latest version from my master degree thesis.

Anyway, it's pretty easy to create custom class (at least using standard Qt classes ) that would operate directly on INI files and expose such API.

Per wrote:...and if someone wants to change everything to use QJson (now part of Qt5) instead, I'm not going to stand in the way of that.

I actually would; mostly because i do not have 10 free gigs to compile Qt5 myself and all later binary versions of Qt from what is currently in use would not work with the mac builds.

Unless, of course, QJson could be made to work with Qt 4.7.4.

dak180, we don't really need that module to support it.
If you want I can paste you pretty short code that uses bits already available in Qt to turn JSON to QVariantMap.

There's JSON object in the WZ 3.1+ JS API that can stringify to and parse from JSON. So I assume there's something lurking in there already that could be used.

When I first saw the ini file format being used, I asked if we could use JSON instead. But having now worked with ini format a bit more, I must admit I quite like it - it's a very clean way to define settings.

In terms of JSON, I think it would make sense to use JSON to store JS objects in save games. Currently there's some ultra-weird gumpf that goes in to the ini file with lots of escaping. Using JSON.stringify(), which automatically removes functions and anything else that you wouldn't want to go in to an ini file, would make JS objects persisted in save games much easier to read and debug.

When a saved game is loaded, you'd just cycle through all the properties in the [globals_N] section, and pseudo code to restore the properties would be something like this:
More info on the JS API's JSON object: https://developer.mozilla.org/en/docs/JSON

Note: I've already used it extensively in my Babel API (source, unit tests).

aubergine, that mess issue can be avoided, one way is custom INI writer (optionally with custom reader) that would allow to convert these values to more readable form (depending on type put them in readable list or split into sub keys). I've suggested that already long time ago, since that output looks terrible, even escaping non ASCII characters (I believe they do those things for a reason, but we don't need such things anyway)...

If it does get updated, it would be useful if non-enumerable globals could be excluded from persistence. Currently only functions and JS API natives are excluded. Being able to mark something as non-enumerable to prevent it going in save game would be very useful as it would reduce the need to create stub functions as namespaces for non-persisted stuff.

aubergine, this is unrelated to QSettings at all.
Without looking for that part of code I can guess that it dumps all objects from script engine and doesn't have enough checks to determine if given object should be saved or not. This requires to write some more dedicated code to save only things that are needed.
But I don't see a way to do it The Right Way without breaking backwards compatibility again.

To avoid such things in future I'm calling for more open and organized model for development. Maybe this project is quite small and doesn't have very many active developers but some design decisions should be at least discussed more openly. And forums aren't proper tool for that (but still better than nothing), although I also don't believe if there would be enough interest to use review board like software. :-/