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

[Martin Heni]

On Monday 10 July 2006 18:01, Dmitry Suzdalev wrote:



> At least I have difficulties in understanding those signals and slots
> which write event data to QDataStream...
A better documentation would not hurt. However, this applies to a lot of 
KDE/OSS stuff. Whoever wants to write documentation would be more than
welcome.

> At the moment I'm not intending anything - I'm collecting information :))).
> Being a newbie, I'm a bit afraid of doing such serious steps as throwing
> away looking-general-purpose classes on my own :).
I think it is a good idea to collect information first before deleting general 
purpose classes....

About kgame:
1. It does need adaptation for KDE 4.0. Several things are outdated like Andi 
mentioned or need to be adapted to the new Qt. Again, anybody volunteering is 
welcome!
2. I think it would be useful to generate more standardized game classes not 
less. Game APIs like DirectX are one of the reasons why games are written for 
other platforms nor KDE. So if someone really has time he could even extend 
the kde game API.

> I'm currently stuck at this.
> KGameMouseIO isn't working with QGraphicsView (so is KGameKeyIO), but other
> IOs work OK.
> What should I do?
I have also only briefly looked at the new Qt API but actually I thing the 
MouseIO should still work. You only need to derive your own GameView from 
QGameView (often a good idea anyway) and emit mouse signals in the 
corresponding mouse methods of QGameView. Connect this as usual to the 
KGameMouseIO and it should work.

As Andi already mentioned the IO modules are a very generic setup. You can 
easily implement your own modules. The implemented modules in KGame 
(Key,Mouse, etc) are only default (and in a way example) IOs. It is no 
problem and often useful to derive your own IO from KGameIO. Then you have 
all freedom what to do in it but still keep the benefit of a modularized IO 
concept.