KDE Plasma 5.1 Now In Beta

[Sho_]

The problem is that the Plasma 5.1 tars depend on Frameworks not available in tar form, so darkbasic is correct that's unfortunate. What's going on is that KDE Frameworks 5.3 will be released in time for Plasma 5.1, so the KWin folks thought it'd be OK to make some improvements to KWindowSystem (a Framework) and depend on them in KWin, not realizing at the time it would cause some problems with the Beta. We've already discussed this in a meeting and will avoid it in the future - lesson learned. It happens with new release processes ...

[Sho_]

KDE has been stupid. They should have been developing wayland ever since 4.6 came out.
4.6 works well and is stable. They should have ended with 4.6 and not gone on to 4.7.
Gnome3, Cinnamon, E19 will be widely adopted with Wayland and likely several versions updated by the time a 1/2 baked buggy as hell KDE Wayland is released.
KDE will never catch up.

KDE actually started on Wayland-related work long before several of the projects you list, FWIW. You're being unnecessarily panicky there.

[pumrel]

KDE actually started on Wayland-related work long before several of the projects you list, FWIW. You're being unnecessarily panicky there.

So how far exactly is KDE in implementing Wayland compared to Gnome, for example? In layman terms as I don't understand the process much.

[grndzro]

KDE actually started on Wayland-related work long before several of the projects you list, FWIW. You're being unnecessarily panicky there.

Well KDE started before the others and the others are nearly complete.
KDE? not even close to being done yet. Too many hands in the cookie jar.

[darkbasic]

Well KDE started before the others and the others are nearly complete.
KDE? not even close to being done yet. Too many hands in the cookie jar.

Did others had to deal with a complete overhault? No, also kde isn't in such a bad shape regarding wayland support.

[Sho_]

So how far exactly is KDE in implementing Wayland compared to Gnome, for example? In layman terms as I don't understand the process much.

The apps generally work fairly well now, to the degree they can (some work is left undone mainly because those things in Wayland haven't been fully spec'ed out yet, which acts as a cap on everyone's efforts). I don't have too much insight into what the Gnomies are doing, but IIRC they're fairly unhappy with how Wayland support is implemented in GTK+ because it was grafted onto GDK fairly haphazardly and still needs some redoing (especially in the face of their scene graph plans, I guess), so it wouldn't surprise me if Qt is overall further along. But you should probably get something more authorative there from a GTK+ dev.

On the Plasma side, it's been a long-term process of initially adding OpenGL ES and EGL support to the compositor, factoring out the X11 stuff, and so on, and then moving on to adding Wayland support. Milestones like running KWin under Weston and accepting clients were accomplished last year already, but things slowed down for a while due to porting to Qt 5 and Frameworks 5. In recent weeks progress on Wayland has been speedy again though, with lots of work going into turning KWin into a full-fledged compositor and designing and implementing the protocols the shell<->KWin interaction needs.

I think Gnome's ahead a bit on the shell side of things since they have a sort-of-working Wayland session now, but Plasma 5 will probably get there before year's end, too. The work won't stop there, though, the Wayland community in general still has a lot of things to figure out.

[valeriodean]

The problem is that the Plasma 5.1 tars depend on Frameworks not available in tar form, so darkbasic is correct that's unfortunate. What's going on is that KDE Frameworks 5.3 will be released in time for Plasma 5.1, so the KWin folks thought it'd be OK to make some improvements to KWindowSystem (a Framework) and depend on them in KWin, not realizing at the time it would cause some problems with the Beta. We've already discussed this in a meeting and will avoid it in the future - lesson learned. It happens with new release processes ...

Theoretically yes, but practically?
Framework is near to be released (tagged on 4th October) so what kind of modification are permitted the last days? Only critical bugfix.

The end user that want to test the Plasma 5.1 beta, will download it from a repository (99% of the cases), so the problem is only on who packages the beta, and even if the framework 5.3 is still a not released software, it's a 4 days left from the tag deadline so pretty much identical to the final version.
Their release data are so close that theoretically you build plasma 5.1 beta on a unreleased software, but practically framework 5.3 is already in its release shape.

[Sho_]

Yeah, it's not a big problem in the grand scheme of things, but it's possible to run into it as darkbasic proved.

[zanny]

So if I understand it correctly, in the future, distros that have been including KDE with a certain version number, like 4.13, will have to state the version number of KDE frameworks, KDE plasma and KDE apps? Like now we have Kubuntu with, say, KDE 4.13, but then we'll have Kubuntu with KDE Frameworks 5.2, KDE Plasma 5.1 and KDE Apps 5.0? That's a bit confusing for the users. How can they know what to expect?

They would be advertising the version of Plasma, the frameworks and individual app versions are irrelevant. A lot of KDE programs already branched off the 3 month release cycle, such as KTorrent, Calligra, Calibre, and Amarok. None of them are on a version 4.14 but distros do not care because they are just supported software.

Likewise, the toolkit library versions are not an indicator of desktop version.

So a distro shipping Plasma 5.1 should be calling it KDE 5.1.

[Sho_]

It's also worth pointing out that the applications have forever had individual version numbers in their About dialogs; version numbers like "3.5" or "4.7" or so always referred to the roll-up.

For KDE Frameworks, unless you're a developer, the version isn't too exciting. It's not much different than, say, the Qt version. Frameworks gets released monthly, even, so you'll quickly lose track of it.

For apps, it's best to just go with their individual versions. Some of them getting released together as "KDE Applications yy.mm" roll-up is done mostly for logistical reasons, it allows the KDE Release team to take care of it instead of individual app maintainers. Some of the larger app teams have always released independently on their own schedule, though (e.g. Amarok or Konversation).

In the end what you really care about is the version of Plasma Desktop, i.e. the workspace shell, and we'll try to help distros clearly communicate that.