Re: KF5 in trunk
On Thursday 22 September 2016 10:30:31 Dwayne MacKinnon wrote: > Thanks for the update. I just used the plasma5 branch a few days ago to > install kf5. Should I now check out trunk and use it from here on? At this point, I'd say stick with plasma5/ branch, since it has all the bells and whistles. trunk/ only has kf5 -- the frameworks, for development purposes, and no desktop or kf5-based applications. If you actually want to try to use Plasma 5 Desktop and KDE Applications, use plasma5/ branch from area51. [ade]
Re: KF5 in trunk
Hi Adriaan, Thanks for the update. I just used the plasma5 branch a few days ago to install kf5. Should I now check out trunk and use it from here on? Thanks, DMK On September 22, 2016 12:27:55 AM Adriaan de Groot wrote: > Recently, area51 trunk was pretty much declared dead. All the good stuff > (tm) was happening in plasma5/ branch, largely thanks to tcb. Having qt 5.6 > and cmake and some other big PRs in-flight didn't help much: trunk was way > out of sync. > > Trunk has been resurrected. > > After some rough-and-tumble merges, it caught up with official downstream > ports recently, and has now had its role restored as the place where "the > next big thing" is prepared. > > Based off of D7645 (which massaged kde.mk and makes USES=kde a lot more > flexible, again thanks to tcb), trunk has now had KDE Frameworks 5 added. > That's the tiers 1, 2 and 3 from https://api.kde.org/frameworks/ , with only > a few exceptions (which can be found in kde.mk). > > Current roadmap is this: > - get D7645 done, so that all the existing kde4 ports use the new mechanics > - merge that into trunk > - flush trunk, now with kf5, downstream in another review / PR > > This can be done because the kf5 ports are all named consistently and don't > collide with anything. Now, just having kf5 ports in the tree isn't going to > buy us any user-visible functionality, but it's good to have that as a > checkpoint anyway: the supporting libraries. > > The map after getting kf5 in has a number of points of interest, but I don't > know what makes the most sense, order-wise: > > - handle the big name-shuffling to make (name)space for co-existence of > KDE4 and KF5-based applications; there's still the discussion to be had > about the desirability of keeping KDE4 apps in some kind of legacy form. > - add plasma5 desktop; this probably doesn't name-collide with anything > else, and could provide a Plasma 5 desktop experience with KDE4 > applications running in it (or, of course, anything else X-based), > - update KDE4 applications to the latest released versions, > - add KF5-based applications to ports. > > [ade]
KF5 in trunk
Recently, area51 trunk was pretty much declared dead. All the good stuff (tm) was happening in plasma5/ branch, largely thanks to tcb. Having qt 5.6 and cmake and some other big PRs in-flight didn't help much: trunk was way out of sync. Trunk has been resurrected. After some rough-and-tumble merges, it caught up with official downstream ports recently, and has now had its role restored as the place where "the next big thing" is prepared. Based off of D7645 (which massaged kde.mk and makes USES=kde a lot more flexible, again thanks to tcb), trunk has now had KDE Frameworks 5 added. That's the tiers 1, 2 and 3 from https://api.kde.org/frameworks/ , with only a few exceptions (which can be found in kde.mk). Current roadmap is this: - get D7645 done, so that all the existing kde4 ports use the new mechanics - merge that into trunk - flush trunk, now with kf5, downstream in another review / PR This can be done because the kf5 ports are all named consistently and don't collide with anything. Now, just having kf5 ports in the tree isn't going to buy us any user-visible functionality, but it's good to have that as a checkpoint anyway: the supporting libraries. The map after getting kf5 in has a number of points of interest, but I don't know what makes the most sense, order-wise: - handle the big name-shuffling to make (name)space for co-existence of KDE4 and KF5-based applications; there's still the discussion to be had about the desirability of keeping KDE4 apps in some kind of legacy form. - add plasma5 desktop; this probably doesn't name-collide with anything else, and could provide a Plasma 5 desktop experience with KDE4 applications running in it (or, of course, anything else X-based), - update KDE4 applications to the latest released versions, - add KF5-based applications to ports. [ade]
