[Kde-games-devel] KGame/KPlayer API usability in kdegames
Martin Heni
martin at heni-online.de
Wed Jul 12 18:51:12 CEST 2006
On Wednesday 12 July 2006 09:17, Dmitry Suzdalev wrote:
> > Why hack? It's the correct solution to a situation where a predefined
> > class can't be used.
>
> Yes, but when the class usage becomes not evident and I have to place
> a workarounds like this here and there, I call it a hack.
> In my terminology at least :).
Yet another idea (again without testing it): It could work if you also derive
your own MouseIO class from the KGameMouseIO and emit the signal from there.
At this point you have the KGameIO pointer (that is "this"). You then
connect the QGraphicsView (Yes indeed I did not mean QGameView) to your
MouseIO. Then you connect your MouseIO to whatever you want.
Obviously you would get the same behaviour by just omitting the IOs classes.
But keeping them gives you another advantages, like the exchangeability etc.
Another option would be to check with Trolltech whether it is possible to have
the events in a new release or whether they left them out on purpose.
I think the keypoint besides an upgrade of the library is the missing
documentation. If someone wants to work on this: I think we still have some
old and basic documentation somewhere. Maybe this can still be found.
Unfortunately, I have no time in doing the docs myself. The little time I
have I need for porting and improving LSkat and KWin4 for KDE4 (btw very good
if you also do the KWin4 porting! Maybe I need not do much there after all!!)
More information about the kde-games-devel
mailing list