No subject

currently be met by a lot desktop video drivers, which is yet another
reason to not immediately go chasing QtQuick 2 rainbow. (Although in
the long run, QML could be very good for KDEGames.)

> 2. Qt3Support and KDE3Support uses need to be removed. I remember to
> have cleared much of it in Kolf in the 4.6 cycle, but there is still
> some Q3* in KSudoku and some Q3* and K3* in ksirk/iris. [1][2]

Tightening up those searches makes the situation look quite a bit better.

http://lxr.kde.org/search?filestring=kde%2Fkdegames%2F.*%28h|cpp|ui%29%24&advanced=1&casesensitive=1&string=Q3*
http://lxr.kde.org/search?filestring=kde%2Fkdegames%2F.*%28h|cpp|ui%29%24&advanced=1&casesensitive=1&string=K3*

But even those contain a few false positives. :)

> These are our duties. What are our wishes? Does anyone of you need
> something in Qt which isn't there at the moment? Is there something
> e.g. in libkdegames which we might want to upstream into Qt? If so,
> please take the chance to speak up.

For the most part, I think the goals and wishes of the KDE project as
a whole during this transition more than cover our game specific
needs.

The one exception that springs to mind is the deprecation of the QtSvg
module, which KDEGames is obviously heavily reliant on. For those not
following that discussion, QtSvg hasn't really seen any work for the
last several years as Qt no longer has any one really capable of
improving it. It only supports SVG 1.2 Tiny, but even then it isn't
fully compliant. Going forward the recommendation seems to be to use
QtWebkit to render SVGs as it is supposed to be quite performant and
support SVG 1.2 Full. Which sounds nice. The problem is that
QSvgRenderer provided a nice simple API to render SVGs, whereas I've
yet to see a clear demonstration of application SVG rendering via
QtWebkit.

Parker