[Kde-games-devel] KGame/KPlayer API usability in kdegames

[Andreas Beckermann]

On Tuesday 11 July 2006 23:34, Dmitry Suzdalev wrote:
> On Wednesday 12 July 2006 01:04, Kleag wrote:
> > Hello,
> >
> > This message to kde-games-delvel :-) to signal that I also use
> > libkdegames/KGame for KsirK (see my signature) and that it was, thanks to
> > it, very easy to change KsirK into a fully network enabled game (while
> > maintaining the possibility of local games).
> > I also uses a lot the message passing API by implementing a kind of
> > automaton that handles messages received from other clients depending of
> > the current state of the game. Maybe this automaton class could be
> > generalized to be used by other games.
>
> So it seems that majority of games make a big use of KGame network
> features, and only (one that I know) kwin4 uses that KGameIO concept. Which
> seems to be useful, but renders to be unusable in QGraphicsView case :).
>
> <sidenote>
> Yesterday Martin suggested a workaround around this limitation (to emulate
> KGame*IO signals by emitting them from QGraphicsView).
> It sounded like a good thing (=good hack), 

Why hack? It's the correct solution to a situation where a predefined class 
can't be used.
Boson doesn't use KGameMouseIO at all, btw.

> but when I looked at the code 
> today I found that
> I miss some data that is needed for signal, because it (the data) belongs
> to another class and there's no way to get it w/o redesigning those
> classes... So I'm stuck again :).

I have no idea what you are talking about.

> </sidenote>
>
> > I must confess that I feel that the level of maintenance of
> > libkdegames/kgame is somewhat low (I don't criticize, I could help too!)

There are some pretty easy reasons for this. For one not many apps in kdegames 
use KGame. And also: boson uses it a lot and every now and then we have a 
small bugfix or even a feature change/addition to it, but it's hard to 
impossible to backport to KDE. At some point code was added to KDE's KGame, 
that made it incompatible with kdelibs < 3.1. It's not an option to Boson to 
require a very recent kdelibs (many, many, many people already complain about 
the kdelibs dependency in general).
So I pretty much can't backport code to KDE - except for trivial bugfixes.

And of course with the port to Qt 4 this has become much worse.

> > and that there is very few up to date documentation. In fact, without the
> > mykgame-1.0 example by Martin Heni I would not have been able to finish
> > the port. And also, I had very helpful answers from this list each time I
> > asked.

This might be a good time for a small break for commercials:
http://www.amazon.com/exec/obidos/tg/detail/-/1584504064/qid=1111776411/sr=8-13/ref=sr_8_xs_ap_i13_xgl14/102-0127414-6683369?v=glance&s=books&n=507846

:-)

> Today is a great day! I understood how passing game moves through
> QDataStreams in KGame's signals/slots work :).
> Can't say that I feel this is a good way, though. Or it needs to be _well_
> documented :). But even in that case I'd rather implement something that is
> more easier to understand.

What exactly is hard to understand about it?
If you have a stream - just use it.
  stream << (int)whatever;
  stream << QString("foo");
and the corresponding receiver side:
  int whatever;
  QString foo;
  stream >> whatever;
  stream >> foo;

I don't see what's hard to understand here. You simply use the streams 
provided by the signal to communicate.
Initiating a communication works pretty much the same - except that you must 
create the stream (since you don't have one yet)
  QByteArray buffer;
  QDataStream stream(buffer, IO_WriteOnly);
(IIRC in Qt4 it looks slightly different - at least IO_WriteOnly was renamed)
And if you don't want that you can still use the KGame::sendMessage(QString 
message, ...) version that does that for you.

CU
Andi