[Kde-games-devel] KGameRenderer Porting Experience

[Parker Coates]

On Thu, Jul 29, 2010 at 02:43, Aaron J. Seigo wrote:
> On July 28, 2010, Parker Coates wrote:
>> Now I'm certainly not saying that we should make everything virtual
>> just in case someone someday might need to customise it, but there are
>> probably some methods that are more likely to need custom code.
>> Personally, I think KGameRenderer::setTheme() and
>
> virtual methods are double edged swords at times. in plasma, we opted for
> signals for things like theme change notification. it allows any object to
> then "do the right thing" and has been invaluable in our usage of theming in
> plasma. if you do go that route, just be sure that the signal has a stated
> policy of -when- it is emitted (e.g. before or after the setTheme() work is
>  done).

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.

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.

This stuff is tricky as it's hard to predict what corner cases will
crop up in different apps. Maybe the best strategy at this point is to
just keep porting new games and watch for common usage patterns.

>> === QPixmap Warnings ===
>>
>> Games using KGR in a K_GLOBAL_STATIC (ex: KDiamond, Killbots)
>> currently generate a lot of "~QX11PixmapData(): QPixmap objects must
>> be destroyed before the QApplication object, otherwise the native
>> pixmap object will be leaked." warnings at shutdown. Do we care? If we
>
> it's a bogus warning. you can ignore it.

Thanks. The last I'd heard it was suspected to be bogus, but it wasn't
known for sure.

Parker