[Kde-games-devel] KMahjongg archaeology

[Ian Wadham]

Hi Roney,

It's great that we can work together again… :-)

On 24/01/2015, at 1:13 PM, Roney Gomes wrote:
> 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.

I checked Jan-Peter's commits.  In order of date:
    a) a1f8504f			2014-12-14 06:02 pm  Merged into kmahjongg.cpp OK
    b) 3c01a441			2014-12-15 11:57 pm  Removed during the merge
    c) 3ddaa76d			2014-12-23 03:57 pm  Removed during the merge
    d) 63fd8bfe			2015-01-02 09:55 pm  Removed during the merge
Re b) and c), equivalent functionality already existed in the qgraphic branch.
I checked this by eyeballing the GameView code and by testing with resizes
and tile-theme changes while the game is paused.  All worked fine.  Tiles
reappeared with correct sizes and faces when the game was unpaused.
Re d), GameView code handles "Rotate View" actions differently.  Overall,
it was OK to remove the obsolete boardwidget.h and boardwidget.cpp files,
during the merge, including Jan-Peter's recent changes to them.

The master versions of CMakeList.txt files were adopted correctly into the
merge.  The docbook parsing errors also exist in the original master branch
on my Apple OS X setup.  They could be an artefact of the way I build, so I am
postponing doing anything about them for now.
    
>>> 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.

So far, I have not found much that really needs doing.  Christian has indeed
done a great job.  Congratulations, Christian!  :-)

I am ready to tidy up and push to origin qgraphic now.  So I will do that today.
Then I will start a new thread on KDE Games.  The QGraphicsView port of
KMahjongg is now "dug up" and very much alive, so no more "archaeology".

Cheers, Ian W.