[Kde-games-devel] How to overwrite a KCFG setting?

Ian Wadham iandw.au at gmail.com
Sun Jan 6 00:19:47 UTC 2013


Hello Parker,

Thank you very much for all this very useful advice.  You have given
me a lot to think about.  For one thing, KJumpingCube's .kcfgc file has
not been changed for 9 years, since Waldo Bastien wrote it.  He was
the author of KCFG itself.

On 04/01/2013, at 11:18 PM, Parker Coates wrote:
> If you need to set a value you should enable the generation of mutator
> methods in your .kcfgc file. To add setters for every property, use
> "Mutators=true". To add setters just a few, use
> "Mutators=CubeDim,SomeOtherProp". Then you can just call
> "Prefs::self()->SetCubeDim( previousCubeDim );" (See [1] for more
> details.)

Thanks very much, I am experimenting with that.

> Personally, when I ran into this issue in Killbots, after a fair bit
> of experimentation, I opted for a slightly different approach. Instead
> of game parameters being pulled directly from KConfig in the game
> logic, it is read just at the start of the game and then cached
> internally. If the user changes ruleset midgame, they are prompted to
> either continue the current game or start a new one with the new rules
> (like your suggestion), but the advantage is that we don't need to
> overwrite the user's rule selection. It'll just be used the next time
> a game is started.

In KJC it is easy to change the board size, deliberately or accidentally, and
not realise the implications.  It is just one of many settings, but the only one
that kills the current game.  So I might stick with the idea of putting the board
size setting back as it was, if the current game is to continue.  In Killbots,
asking for a change in rules feels (to me) like a quite deliberate action, so
I agree with your approach in that case.


> I wouldn't argue that my solution is necessarily better than yours, it
> just happens to match what I personally would expect as a user. For
> the code in question, see [2].

I like your idea of deferring the settings change.  As it is now, the signal can
come in during AI activity (now on a thread) or during animation.  In such cases
I definitely would like to keep going with what settings I have and implement
the change(s) at the next suitable break in activity.

Thanks again, Parker.

Cheers, Ian W.

> [1] http://api.kde.org/4.9-api/kdelibs-apidocs/kdecore/html/kconfig_compiler.html
> [2] https://projects.kde.org/projects/kde/kdegames/killbots/repository/revisions/master/entry/mainwindow.cpp#L97


More information about the kde-games-devel mailing list