[Kde-games-devel] Merge frameworks in master

[Ian Wadham]

Hi Jeremy,

On 01/01/2015, at 11:53 PM, Jeremy Whiting wrote:
> On Wed, Dec 31, 2014 at 8:31 PM, Ian Wadham <iandw.au at gmail.com> wrote:
> 
> Ian said: As far as I am aware, and I think I heard this from Albert on another list, there
> will be no further releases from master --- KDE 4.14 was the last one.  Indeed,
> if I understand correctly, the concept of "master" is obsolete in Frameworks/KF5
> and releases are done from parallel repositories, e.g. Dr Konqi source code
> exists in the kde/kde-runtime repository and also (temporarily, I am told) in
> plasma-workspace repository on KF5.
> 
> Jeremy: This is a misconception. Only "kdelibs" no longer has a master branch that
> gets released. That is simply because it has been split into many smaller git repos
> "the frameworks" which are released from master branch. All applications in
> Applications releases come from their respective master branches.

Ah, OK, thanks.  I guess it was the two-repository setup for kde-runtime that
had me confused.

> Yes, I believe Laurent means merging frameworks+master -> master. Also as he said you can continue to build kdelibs4 based applications with kdesrc-build, simply set:
> branch-group latest-qt4
> in your global options as documented in kdesrc-build/kdesrc-buildrc-sample which will use the latest qt4 based branch of all libraries and applications.

I am already using "branch-group latest-qt4", but the description in kdesrc-buildrc
is "- latest-qt4 (the upcoming KDE 4 release)", which is obviously out-of-date… :-)
The repository at
https://projects.kde.org/projects/extragear/utils/kdesrc-build/repository/revisions/master/entry/kdesrc-buildrc-sample 
says the same about "branch-group latest-qt4".  What I get from it is a mixture of
branches: KDE/4.14 for kdelibs and master for KDE Games, which I think is as it
should be at the moment.  If Laurent merges the frameworks branches of KDE
Games into the master branches, I doubt if kdesrc-build's "latest-qt4" will be
able to spot the boundary-lines within the master branches.

So maybe I should drop back to "- stable-qt4 (the last KDE 4 release, plus bugfixes)"
for any downstream KDE Games work I may wish to do.  I am only on "latest-qt4" for
the work I was doing on fixing kde-runtime/drkonqi.

> Ian said: BTW KSudoku and Kubrick depend on OpenGL and Qt's support for OpenGL
> widgets, a requirement that is not so common in other KDE software, I believe.
> I hope this will not present any problems re porting to Frameworks/KF5.
> 
> Jeremy said: The porting has been done from what I see, the only question is which
> version (qt4/kdelibs4 based or qt5/kf5 based) will be used for the upcoming spring release
> (which will most likely be called Applications/15.04).

Laurent has ported 3 of the 5 games I maintain: KGoldrunner, KJumpingCube and Palapeli.

Of the other two, KSudoku has a frameworks branch, but from what I can see, there is essentially
no new code there --- so the porting has not yet been done.  And Kubrick does not yet have a
frameworks branch.  I am looking at https://projects.kde.org/projects/kde/kdegames/kubrick/repository.

> Ian, If it helps I can do some testing on linux of the frameworks branches before they are merged.

Thanks, Jeremy, that would be a great help.  I can contribute too, by eyeballing the changes,
suggesting some stringent tests, providing desired results and helping with the debugging
aids and messages, if we need them.

The top-level changes for KF5 should not be a huge problem.  My greatest worry is that something
nasty will turn up in the internals of Qt 5.  It has happened before.  The KGoldrunner graphics, in
particular, have had to be re-written 6 times in the 13 years since I first checked KGoldrunner in.

I also had to write a super-class for QTimer, because the Qt 4 version omits signals quite often.
That is a feature, not a bug.  QTimer is not intended to be super-precise in real time.

BTW is Qt 5 still using raster graphics?  There is a bongle in libkdegames that makes it mandatory.

> I also like Albert's idea of having one day per application to test/debug these. We can blog
> about it and get some community members to test one application each day on linux to check
> for any regressions before merging the frameworks branches to master.

The key will be to get people who know how to play the games and are familiar with the
various options, settings and flow of control (gameplay).

Cheers, Ian W.