WzConfig

For code related discussions and questions
Post Reply
User avatar
NoQ
Special
Special
Posts: 6226
Joined: 24 Dec 2009, 11:35
Location: /var/zone

WzConfig

Post by NoQ »

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 (:
Per
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 3780
Joined: 03 Aug 2006, 19:39

Re: WzConfig

Post by Per »

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.
User avatar
NoQ
Special
Special
Posts: 6226
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: WzConfig

Post by NoQ »

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. (:
User avatar
Emdek
Regular
Regular
Posts: 1329
Joined: 24 Jan 2010, 13:14
Location: Poland
Contact:

Re: WzConfig

Post by Emdek »

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.
Nadszedł już czas, najwyższy czas, nienawiść zniszczyć w sobie.
The time has come, the high time, to destroy hatred in oneself.


Beware! Mad Qt Evangelist.
User avatar
dak180
Trained
Trained
Posts: 288
Joined: 01 Nov 2009, 23:58
Location: Keeper of the Mac Builds

Re: WzConfig

Post by dak180 »

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. :lecture:
User:dak180
Keeper of the Mac Builds
User avatar
Emdek
Regular
Regular
Posts: 1329
Joined: 24 Jan 2010, 13:14
Location: Poland
Contact:

Re: WzConfig

Post by Emdek »

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.
Nadszedł już czas, najwyższy czas, nienawiść zniszczyć w sobie.
The time has come, the high time, to destroy hatred in oneself.


Beware! Mad Qt Evangelist.
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: WzConfig

Post by aubergine »

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:

Code: Select all

for each player (N):
   load their section of the ini [globals_N]:
      for each property in that section:
          global[propertyName] = JSON.parse(iniSection[propertyName])
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).
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
Emdek
Regular
Regular
Posts: 1329
Joined: 24 Jan 2010, 13:14
Location: Poland
Contact:

Re: WzConfig

Post by Emdek »

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)...
Nadszedł już czas, najwyższy czas, nienawiść zniszczyć w sobie.
The time has come, the high time, to destroy hatred in oneself.


Beware! Mad Qt Evangelist.
User avatar
aubergine
Professional
Professional
Posts: 3459
Joined: 10 Oct 2010, 00:58
Contact:

Re: WzConfig

Post by aubergine »

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.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
User avatar
Emdek
Regular
Regular
Posts: 1329
Joined: 24 Jan 2010, 13:14
Location: Poland
Contact:

Re: WzConfig

Post by Emdek »

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. :-/
Nadszedł już czas, najwyższy czas, nienawiść zniszczyć w sobie.
The time has come, the high time, to destroy hatred in oneself.


Beware! Mad Qt Evangelist.
Post Reply