[Kde-games-devel] KMahjongg archaeology

[Ian Wadham]

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.

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

Cheers, Ian W.