[Kde-games-devel] Merge frameworks in master

[Ian Wadham]

Hi Albert and Laurent,

Thank you very much, Laurent, for all your work on this.  I particularly
appreciate you tackling KGoldrunner and Palapeli, which are quite
large code-bases.

On 31/12/2014, at 9:54 AM, Albert Astals Cid wrote:
> El Dimarts, 30 de desembre de 2014, a les 20:59:44, laurent Montel va 
> escriure:
>> Hi,
>> As you saw I worked on porting to kf5 some kdegames application
>> (http://www.aegiap.eu/kdeblog/2014/12/kf5-kdegames/)
>> 
>> I removed kdelibs4support for several applications.
>> I converted to reverse dns desktop
>> I fixed cmake file
>> I fixed a lot of bugs
>> etc.
>> 
>> And you can see that:
>> "bomber
>> bovo
>> granatier
>> kapman
>> katomic
>> kblackbox
>> kblocks
>> kbounce
>> kbreakout
>> kdiamond
>> kfourinline
>> kgoldrunner
>> kigo
>> killbots
>> kiriki
>> kjumpingcube
>> klickety
>> klines
>> kmahjongg
>> kmines
>> knavalbattle
>> knetwalk
>> kolf
>> kollision
>> konquest
>> kshisen
>> ksnakeduel
>> kspaceduel
>> ksquares
>> ktuberling
>> libkdegames
>> libkmahjongg
>> lskat
>> palapeli
>> ‟
>> Compile against on kf5.
>> 
>> Now I would like to merge in master as I think it's a good idea to have it
>> in next kde release 'kde-15.3„ kde-15.4„ I don't know when it will release.
>> 
>> What do you think about it ?
> 
> Do we know if libkdegames and libkmahjongg co-install fine with their kdelibs4 
> counterparts? Because if they do not, we need to move *all* the projects at 
> once from kdelibs4-based to kf5-based, which may not be ideal.
> 
> For the things i maintain (i.e. ktuberling and kiriki) I'd like to do the 
> merge from frameworks to master myself, i agree with you they should go into 
> next Applications [not kde ;)] release if they are good. I'll have a look on 
> the coming weeks.
> 
> What the maintainers of the others say?

I am still the maintainer of KGoldrunner, KJumpingCube, KSudoku, Kubrick and
Palapeli.

Merging the Frameworks versions into master would make it impossible for me
to work on them in the foreseeable future.  The reason is that I work on an Apple
MacBook using OS X operating system and nobody has yet succeeded in building
and running Frameworks-based applications on that platform.

We have one guy (Marko Käning) working on it, but he is on Christmas holidays
now.  He is using Bovo and KMahjongg as test cases.  Just before Christmas he
reported that he had KMahjongg running, but it would not Quit properly…

Also, there are ongoing debates on KDE Software on Mac OS X <kde-mac at kde.org>
about fundamentals, such as:

   - How to install, build and use Qt 4 and Qt 5 concurrently.
   - How to set up defaults for the XDG_* directories [1].

And I am using KDE4-based builds of the games that I maintain as test-applications
for diagnosing and fixing bugs in KDE 4 internal libraries, utilities and apps.  See
https://bugs.kde.org/show_bug.cgi?id=337742.  That bug has been crippling Dr Konqi
on Apple OS X, Linux+KDE4 (which a lot of users still have) and Linux+KF5.

Lastly, there are still many things about KDE4 that do not work properly on Apple
OS X and our group on kde-mac at kde.org are working our way through them.  We
believe this is worth doing because it may well be a year or more before we have
KF5 released and running via MacPorts and the last of the KDE4 apps ported to
both KF5 and Apple OS X (via MacPorts).  Also, many of the problems we find and
fix in KDE4 will also need fixing in KF5 on Apple OS X.  The Dr Konqi bug is just
a small example.  We find games and other KDE4 apps valuable in helping to
diagnose the problems and test fixes.

So please, please hold your horses for now, Laurent… :-)  Please do not merge
the frameworks branch into master.

> For the ones without maintainer I would be hesitant to merge them all at once, 
> compiling is veeeeeeery far from running 100% good.
> 
> Maybe we could do something like "the day of Y", where we merge the "ones 
> without maintainer" every few days and ask everyone to try to see if they can 
> find a regression?

I read your blog re testing games you have ported, Laurent.  My advice is to try
and pick games that have Demo or computer v. computer settings.  Such games
exercise a lot of their code automatically, so you can do a quick test without needing
to know how to play them.  If you find any porting errors, check if you have made
similar errors in the other games.

Palapeli also has five demo jigsaw puzzles.  If you can get as far as displaying
a list of them, you have exercised quite a lot of Palapeli, including loading a
plugin to slice the demo puzzles into pieces from the image files as distributed.
You then need to open a demo puzzle and try fitting a few pieces together.

@Albert:
There is a lot more to Palapeli than that and I cannot test it on KF5, so would
you be releasing Palapeli/KDE4 and Palapeli/KF5 concurrently in Applications
releases, where Palapeli/KF5 would be a kind of beta?

Cheers, Ian W.

[1] /usr and /usr/local cannot be used in QStandardPaths because Apple OS X
     already uses them, sometimes with versions of code that conflict with those
     used in FOSS.  David Faure has been showing an interest in this.