<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 2, 2015 at 11:32 PM, Ian Wadham <span dir="ltr"><<a href="mailto:iandw.au@gmail.com" target="_blank">iandw.au@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Jeremy,<br>
<div><div class="h5"><br>
On 03/01/2015, at 2:10 AM, Jeremy Whiting wrote:<br>
> Actually kdesrc-build is quite capable of handling this transition. I'll explain below.<br>
><br>
> On Fri, Jan 2, 2015 at 12:03 AM, Ian Wadham <<a href="mailto:iandw.au@gmail.com">iandw.au@gmail.com</a>> wrote:<br>
> Hi Jeremy,<br>
><br>
> On 01/01/2015, at 11:53 PM, Jeremy Whiting wrote:<br>
> > On Wed, Dec 31, 2014 at 8:31 PM, Ian Wadham <<a href="mailto:iandw.au@gmail.com">iandw.au@gmail.com</a>> wrote:<br>
> ><br>
> > Ian said: As far as I am aware, and I think I heard this from Albert on another list, there<br>
> > will be no further releases from master --- KDE 4.14 was the last one.  Indeed,<br>
> > if I understand correctly, the concept of "master" is obsolete in Frameworks/KF5<br>
> > and releases are done from parallel repositories, e.g. Dr Konqi source code<br>
> > exists in the kde/kde-runtime repository and also (temporarily, I am told) in<br>
> > plasma-workspace repository on KF5.<br>
> ><br>
> > Jeremy: This is a misconception. Only "kdelibs" no longer has a master branch that<br>
> > gets released. That is simply because it has been split into many smaller git repos<br>
> > "the frameworks" which are released from master branch. All applications in<br>
> > Applications releases come from their respective master branches.<br>
><br>
> Ah, OK, thanks.  I guess it was the two-repository setup for kde-runtime that<br>
> had me confused.<br>
><br>
> > 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:<br>
> > branch-group latest-qt4<br>
> > 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.<br>
><br>
> I am already using "branch-group latest-qt4", but the description in kdesrc-buildrc<br>
> is "- latest-qt4 (the upcoming KDE 4 release)", which is obviously out-of-date… :-)<br>
> The repository at<br>
> <a href="https://projects.kde.org/projects/extragear/utils/kdesrc-build/repository/revisions/master/entry/kdesrc-buildrc-sample" target="_blank">https://projects.kde.org/projects/extragear/utils/kdesrc-build/repository/revisions/master/entry/kdesrc-buildrc-sample</a><br>
> says the same about "branch-group latest-qt4".  What I get from it is a mixture of<br>
> branches: KDE/4.14 for kdelibs and master for KDE Games, which I think is as it<br>
> should be at the moment.  If Laurent merges the frameworks branches of KDE<br>
> Games into the master branches, I doubt if kdesrc-build's "latest-qt4" will be<br>
> able to spot the boundary-lines within the master branches.<br>
><br>
> kdesrc-build uses kde-build-metadata to know which branch of each project to build for the different configurations. I believe when laurent merges frameworks to master he'll update (or add) the branch information to kde-build-metadata so latest-qt4 will be Applications/14.12 instead of master for the applications he merges. We've done similarly in kdeedu with success.<br>
><br>
><br>
> So maybe I should drop back to "- stable-qt4 (the last KDE 4 release, plus bugfixes)"<br>
> for any downstream KDE Games work I may wish to do.  I am only on "latest-qt4" for<br>
> the work I was doing on fixing kde-runtime/drkonqi.<br>
><br>
> If we decide to merge the ported games to master branches (you guys decide, not me I'm just a lurker) then I suggest you continue to use latest-qt4.<br>
><br>
><br>
> > Ian said: BTW KSudoku and Kubrick depend on OpenGL and Qt's support for OpenGL<br>
> > widgets, a requirement that is not so common in other KDE software, I believe.<br>
> > I hope this will not present any problems re porting to Frameworks/KF5.<br>
> ><br>
> > Jeremy said: The porting has been done from what I see, the only question is which<br>
> > version (qt4/kdelibs4 based or qt5/kf5 based) will be used for the upcoming spring release<br>
> > (which will most likely be called Applications/15.04).<br>
><br>
> Laurent has ported 3 of the 5 games I maintain: KGoldrunner, KJumpingCube and Palapeli.<br>
><br>
> Of the other two, KSudoku has a frameworks branch, but from what I can see, there is essentially<br>
> no new code there --- so the porting has not yet been done.  And Kubrick does not yet have a<br>
> frameworks branch.  I am looking at <a href="https://projects.kde.org/projects/kde/kdegames/kubrick/repository" target="_blank">https://projects.kde.org/projects/kde/kdegames/kubrick/repository</a>.<br>
><br>
> Ah, I see. In this case I strongly suggest creating a wiki page similar to <a href="https://community.kde.org/KDEEdu/RouteToKF5" target="_blank">https://community.kde.org/KDEEdu/RouteToKF5</a> to track the progress of each game. This was very handy when preparing for the last release in kdeedu module. Laurent, would you create such a page with what you've done so far? That would help immensely to coordinate which games still need to be ported and who is working on said ports etc.<br>
><br>
><br>
> > Ian, If it helps I can do some testing on linux of the frameworks branches before they are merged.<br>
><br>
> Thanks, Jeremy, that would be a great help.  I can contribute too, by eyeballing the changes,<br>
> suggesting some stringent tests, providing desired results and helping with the debugging<br>
> aids and messages, if we need them.<br>
><br>
> The top-level changes for KF5 should not be a huge problem.  My greatest worry is that something<br>
> nasty will turn up in the internals of Qt 5.  It has happened before.  The KGoldrunner graphics, in<br>
> particular, have had to be re-written 6 times in the 13 years since I first checked KGoldrunner in.<br>
><br>
> I also had to write a super-class for QTimer, because the Qt 4 version omits signals quite often.<br>
> That is a feature, not a bug.  QTimer is not intended to be super-precise in real time.<br>
><br>
> BTW is Qt 5 still using raster graphics?  There is a bongle in libkdegames that makes it mandatory.<br>
><br>
> > I also like Albert's idea of having one day per application to test/debug these. We can blog<br>
> > about it and get some community members to test one application each day on linux to check<br>
> > for any regressions before merging the frameworks branches to master.<br>
><br>
> The key will be to get people who know how to play the games and are familiar with the<br>
> various options, settings and flow of control (gameplay).<br>
><br>
> Yep, I can blog about it, I'm sure we have many community members that enjoy the various games and would be happy to test the latest version if we have:<br>
> 1. Clear instructions for building/installing them<br>
> 2. A coordinated page of what has been tested in each game that contributors can easily update (I suggest a wiki, low barrier to entry)<br>
<br>
</div></div>That is an excellent plan.  I am sending all of the above via the KDE Games list,<br>
as I think you just sent it privately before.<br>
<br>
Cheers, Ian W.<br>
<br>
</blockquote></div><br></div><div class="gmail_extra">Doh, my bad.<div><br></div><div>At any rate, Laurent, can you create said wiki page of which games have been ported, and which are in progress, and which need someone to start them, etc? If you do that I'll blog/send an e-mail get people (maybe just me, we'll see) to test the games that have been merged to master branch.</div><div><br></div><div>thanks,</div><div>Jeremy</div></div></div>