[Kde-games-devel] libkdegames v5

[Stefan Majewsky]

Hi everyone,

while I have not been active in development lately, I have been monitoring the
developments in KDE land, especially the development of Qt 5 and kdelibs 5 (aka
"frameworks"). This makes me wonder how we should react to this in kdegames, as
we also maintain a public library, libkdegames.

The change to Qt 5 is the ideal opportunity to break binary compatibility. The
first obvious point is to move the carddeck stuff into libkcardgame. Wasn't
this intended to become public API at some point anyway?

===== 1. API cleanup =====

But that is just the low-hanging fruit. I want to argue for using this
opportunity to remove large bits of libkdegames from the public API, and also
fix some minor annoyances. I would like to go as far as removing the following
things from the public API:

1. KGameCanvas
2. the KGame framework
3. unused stuff like KGameSvgDigits, KGameProgress or KGameMisc
4. KGGZ

KGameCanvas is probably the only non-controversial point here: New applications
should really use QGraphicsView or QSceneGraph from Qt 5. Please note that I'm
not voting for deleting this code, I want to remove it from the public API.
This just means to not install header files for these classes anymore.

For all the other points, this step may sound rude, because this code is
perfectly working at the moment. The reason for this proposal goes deeper than
that.

A shared library with a public API, especially if it has regular releases like
libkdegames has, comes with an implicit maintenance promise. If one provides a
regularly updated interface, third parties will assume that the library itself
is also maintained.

As a counter-example, the last commit on libkdegames/kgame (except for the usual
style fixes) was in late 2008. And that was the only substantial commit that
year. KGame is only used by KFourInLine and KSirk, by the way.

Most of our games are already barely maintained. We shouldn't risk breaking
third-party games by offering API which we cannot guarantee works because we
don't even use it ourselves.

The case of KGGZ is special. It is said to work, but I cannot recall seeing it
work. The only person who knows the code (Josef) has not been able to merge his
rewrite since four years. (No offense meant, I know about his work obligations.)

In the special case of KGGZ, I vote for removing it both from the library and
from applications. I cannot see how it provides value for users, and I feel that
its mere existence constitutes a mental barrier for those who want to introduce
multiplayer functionality into our games using different technologies. (I recall
myself being skeptical towards a proposal of using Telepathy for multiplayer
functionality in a non-KGGZ-powered game, because KGGZ existed already.)

tl;dr: Let's remove most of the public API of libkdegames, at least as long as
       we can't fulfill the implicit maintenance promise.

My detailed proposal is to compile a list of all API which we want to remove
depublicize in libkdegames 5, and mark that API as deprecated. Possible
resolutions for how to remove classes from public API include:

1. Delete the code.
2. Keep the code in libkdegames, do not install the header. (The API is only
   available to existing games in the kdegames module.)
3. Move the code into a libkdegames_private, do not install the header.
   (Functionally equivalent to 2, but the code is at a different place.)
4. Move the code into the source tree of the only game using it.

===== 2. Merge parts of Tagaro =====

I have some code that could be integrated with libkdegames. I'm especially
looking at Tagaro, most prominently the audio API. Also, Tagaro's theming and
difficulty APIs can potentially succeed KGameTheme and KGameDifficulty.

I'm unsure about Tagaro's rendering API, which is intended to succeed
KGameRenderer. This code might be over-engineered.

Furthermore, I might revive my KScore2 patch.

===== 3. Modularize into logic and UI =====

This last point is centered around the changes implied by Qt 5. libkdegames
should stay relevant for new games based on QML/QtQuick2. The relevant API
additions (i.e., our own QML components) can be done later, when the actual
requirements are clear. What we need to do now (that is, with the switch to Qt5)
is to decouple logic classes from QWidget-based interface classes.

QML-based games should not have to pull in a QtWidgets dependency to use logic
classes from libkdegames. For example, KGameDifficulty currently references
KXmlGuiWindow to display the difficulty combobox. This has to be decoupled.

===== The end: Action plan =====

As usual, this mail is an RFC, though only for the first of the three
points. The
Tagaro merge parts will be discussed on reviewboard when the patches are ready,
and the third point I consider the continuation of already effective policies
for kdelibs5.

In order to prepare libkdegames5 (in sync with the frameworks effort
of kdelibs), I would like to move libkdegames to git *now*, even if
the rest of kdegames is not prepared to follow. Judging from the
current development speed of libkdegames, game developers should be
safe to continue using libkdegames 4.8. The only uncertainty here is
that I do not know whether release-team likes modules that have
partially transitioned to Git.

Greetings
Stefan