[Kde-games-devel] KMahjongg archaeology

[Roney Gomes]

2015-01-23 1:20 GMT-03:00 Ian Wadham <iandw.au at gmail.com>:
> Hi Roney and guys,
>
> Guys, please note the questions raised in the last few paras of this post.
>
> On 22/01/2015, at 10:56 PM, Roney Gomes wrote:
>> 2015-01-22 8:33 GMT-03:00 Ian Wadham <iandw.au at gmail.com>:
>>> Well, I was following the plan Laurent and Albert both recommended earlier in this
>>> thread, about 11 days ago.  Too bad.  That would have kept the qgraphic code in
>>> KDE 4 until it would be well-tested and ready to merge into the frameworks branch.
>>>
>>> If we can only build and test the qgraphic code using KF5 now, then I must bow out.
>>> I cannot run KF5/Frameworks/Qt5 on my Apple MacBook.  So I cannot help with the
>>> qgraphic code any more.
>>>
>>> Never mind, I have plenty of other stuff to work on over on KDE-Mac… :-)
>>>
>>> I hope that what I have reported so far about the qgraphic code will be helpful.
>>
>> Well, as Albert just said, forced pushes are not allowed thus rebasing
>> is no longer a possibility. As I'll have to starting merging from
>> scratch again I don't mind merging master first.
>
> I did a trial merge, in my local repository, of master into qgraphic.  It went well,
> after I dealt with the immediate conflicts.  It compiled, built and ran first time, with no
> problems when playing a couple of games.  That was with KDE 4 on Apple OS X.
>
> The main conflict is that the files boardwidget.* are *removed* from the qgraphic
> branch (QGraphicsView does things differently), but Jan-Peter has committed
> 4 commits to master, in that general area, since 14 December.  Parts of these
> commits need to be re-implemented in the QGraphicsView setup and some parts
> will just have to be dropped, being no longer applicable to the QGV code.
>
> Also there are some one-line changes that should use the master version (e.g.
> in CMakeList.txt files) and there were some errors in parsing the docbook.
>
> I will have a go at fixing those things in the next day or two.
>
>> Even though you have plenty of things to do on KDE-Mac this way I may
>> count on your eventual assistance. A second opinion is always
>> appreciated in this case.
>
> I think you and I can work this way, Roney:
>
>   1. I commit and push the merge of master into qgraphic, plus adjustments
>        to the cases where the merge has gone the wrong way (see above).
>   2. You can, if you wish, set up another branch, based on the frameworks branch,
>        and merge the qgraphic branch into your new branch.
>   3. Then I can test and debug the QGraphicsView code on KDE 4 and you can
>        test and debug it on KF5 and we can exchange fixes via patches or cherry-
>        picked commits.
>    4. After that, we can apply Jan-Peter's patches using the same workflow, porting
>        them to QGV whenever required.
>    5. Finally, if all goes well, we can merge your branch into master and release
>        KMahjongg on KF5, with QGV and Jan-Peter's fixes.  Or, if it turns out badly,
>        we can fall back to the frameworks branch, as it currently stands, and release
>        that.

Perfect, but to avoid future headaches I prefer to conclude the
QGraphicsView port first then worrying about KF5 just later. Only now
I realize how much work we have ahead on 'qgraphics'. I was thinking
this port was nearly concluded so I wasn't giving it the necessary
priority.

> Leaving aside git mechanisms for a moment, all this pre-supposes that we do
> actually wish to go ahead with the qgraphic branch.
>
> Please would you and others have a look at what I said about the factoring
> in that code.
>
> It is not ideal, but it works, gets rid of an obsolete KDE Games library and has
> snappier graphics performance than the current KMahjongg.
>
> Do we want to accept that code as is?  Does someone want to re-factor it?
> Or should we abandon the qgraphic branch?
>
> I am in favor of accepting the code as is, for reasons I discussed previously
> (on 21 January in this thread).

Me too. Why start from scratch when there's so much done? Christian
has done a great job already. If we eventually disagree on some of the
design decisions he made, then we change the parts affected.

I'll separate some time to read the code more carefully taking into
account what you have reported on the last e-mails. As soon as you
push the merging result we can define some tasks and start working.
-- 
Roney