[Kde-games-devel] Questions about porting kolf

[Albert Astals Cid]

A Dimecres 08 Novembre 2006 22:11, Paul Broadbent va escriure:
> Hi,
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! 

Of course ;-)

> 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.

That's it.

> 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?

Yes.

>
> 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?

Add yourself.

> 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?

Member variables of the class.

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

Keep up the good work!

Albert

>
> Thanks
>
> Paul Broadbent
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel