[Kde-games-devel] Questions about porting kolf

[Paul Broadbent]

Hi,

I've been looking over the kolf code and I think I have a pretty good feel for 
the basics of how it works, so now I'm gonna try to get the KDE 4 port done. 
I just compiled and installed all the basic kde stuff and kgames from the 
subversion, with the help of this very handy guide:
http://wiki.kde.org/tiki-index.php?page=KDE3To4
To my surprise kolf runs! I suppose someone has already done the very first 
steps for porting, so now my job is to fix all the crazy bugs (and not so 
crazy bugs) and remove all the uses of old headers, such as those whose name 
begins with Q3.

I think I'm going to try porting the graphics to QGV, rather than KGameCanvas. 
This is because I have already worked with QGV a little and in an earlier 
thread Mauricio Piacentini said not to use KGameCanvas unless you understand 
the differences (which I certanly don't!) or you have a good reason to and, 
as far as I know, I don't. However, I have a couple of questions regarding 
the suitability of QGV:

1)
In an earlier thread Dmitry Suzdalev said:
> I remember that the major issue was that many of kolf's QCanvasItem
> subclasses reimplement QCanvasItem::move() function which was virtual in
> Qt3. In Qt4 it is replaced by QGraphicsView::setPos() which is not virtual
> and hence can't be safely reimplemented in subclasses. And this introduces
> drawbacks that need some redesign desicion.

However, I've looked around the kolf code and I can't find any times where 
QCanvasItem::move() is reimplemented. Thats assuming I have the correct 
understanding of what reimplementation is, am I right in thinking it is when 
you redefine a function to modify what it normally does? So if move had been 
reimplemented then running "grep move\( *h" from the kolf directory would 
return something? If kolf does not reimplement QCanvasItem::move() then I 
think that changing it to use QGraphicsView::setPos() should be fairly 
straightforward.

2) In a private email, Mauricio mentioned that there had been a problem 
porting kolf to QGV because QGV does not allow placing of canvas items inside 
other canvas items. I don't know enough about QGV to understand this problem, 
so could someone please explain it to me.


I also have a few other more general questions:

3) What should I do about code that is no longer used? There are some 
variables that are set to false and then never accessed again. Also there are 
a few whole sections of code that are never used (for example the code for 
ball wobble in kolf). If I am certain code is not being used, and is not 
likely to be useful in the future, should I just remove it when I do the 
port?

4) Do I need to think think about future graphical modifications when doing 
the inital port to QGV? All the screen shots of games using SVG look awesome, 
I'm not sure how to translate this style of kolf, but I'll probably want to 
use some SVG graphics at some point. For now would it be best to just do a 
basic port using the current graphics, or does changing to things like SVG 
mean a fundamental graphical change that I'd want to start thinking about 
now?

5) Should kolf still be marked as "needs maintainer" in the wiki, or should I 
now be provisionally marked as the maintainer?

6) Finally a very minor question, in kolf there seem to be many variables 
whose name begins with "m_", but I can't see any connection between these 
variables. Is there some naming convention that I'm unaware of?

Sorry for the incredibly long post, this is all very new to me!

Thanks 

Paul Broadbent