[Kde-games-devel] KGameRenderer Porting Experience

[Stefan Majewsky]

On Thursday 29 July 2010 05:43:15 Parker Coates wrote:
> There is already a
themeChanged() signal in KGameRenderer. Initially I
> was connecting it to a
custom slot for to clear the cache, but then
> ran into issues as some other
slots attached to the same signal ended
> up using the old cached properties
before the clearCache slot got
> called.

Signals have, by definition, no
reliable calling order for the attached slots. You could work around this
limitation by connecting clearCache() with DirectConnection, and all other
signals with a QueuedConnection, but that's really suboptimal.

> I guess
one option for me would to add a themeChangedAndReady() signal
> that only
gets emitted once the theme has changed and the cache has
> been cleared.
Then I could use it for external connections instead of
> themeChanged().
Not pretty, but not that bad.

Actually, I consider this solution best. If
you need more semantics in the calling order of the slots attached to
themeChanged(), you want to define a new signal that implements the
additional semantics.

The other solution would be an themeAboutToBeChanged
signal in the base class, which triggers clearCache() in Killbots. However,
this solution has the problem that it is quite complex to determine when
this signal needs to be emitted in the base class. KGameRenderer tries hard
to abort a theme change if it runs into problems, and I do not want to emit
the signal before it is clear that the theme will really
change.

Greetings
Stefan