KDE Has Another Week Worth Of Wayland Fixes

[duby229]

Except the list of things that can't be fixed because of X11, aka the reasons why the Xorg devs created Wayland.

I think what you mean is, the list of things Wayland can't do because it's a project that only has the capability of being a (extremely limited) display protocol.... IOW, almost everything that Xorg -is- needs to be re-invented and not just once but by every single compositor....

[R41N3R]

Nice to see the spectacle Wayland issue being fixed :-) This was quite annoying.

[bug77]

At this point, what still doesn't work with KDE on Wayland?

KDE devs label Wayland support as experimental. So... quite a lot.
I have recently tried KDE Wayland for less than half an hour and have reported 3 bugs as a result.

[oiaohm]

I think what you mean is, the list of things Wayland can't do because it's a project that only has the capability of being a (extremely limited) display protocol.... IOW, almost everything that Xorg -is- needs to be re-invented and not just once but by every single compositor....

That is not true. You have the libwayland-server and wlroots stuff that provides a lot of foundation stuff included in. Yes libwayland-server includes parts that are not part of the Wayland protocol. What ever is provided by libwayland-server and wlroots each compositor does not have to-do themselves. So Wayland compositors can save themselves a lot of work by working upstream on the libraries they depend on.

Sorry the idea that lot of stuff that was part of Xorg has to be reinvented in every single compositor is not true. It has to be reinvented in a library that all the wayland compositors use in the ideal case. Some features reinvented outside wayland composer completely.


Remember Xorg was not the only X11 server and is not the only one either https://en.wikipedia.org/wiki/List_of_display_servers.

[horizonbrave]

Wayland might be slow developing, but not sure how compares to the long history of Xorg/X server.. also consider that a relevant funding partner (can anyone confirm this please?) like Samsung pull out its support. Open source is amazing but funding is an in a issue if you don't have it sorted somehow. Look at those dick heads at Gnome, no fucking interaction at all with the community other than sending people to GitHub (can imagine a newbie?). But apparently Gnome doesn't seem to miss funds, I guess just a leadership problem. Hope the KDE project is gonna simplify its DE settings framework and I'll be more than happy to give it a go. I also still have a bit of faith in Gnome, perhaps IBM is going to inject some money and someone will try to establish a leadership or roadmap for the future, such a shame that such a polished DE is not able to create a 2 way communication channel with its user base (not developers! but everyday fucking users).
Good night gnome, good morning ...

[curfew]

I think what you mean is, the list of things Wayland can't do because it's a project that only has the capability of being a (extremely limited) display protocol.... IOW, almost everything that Xorg -is- needs to be re-invented and not just once but by every single compositor....

Yes and no. Having a well-defined protocol at the core is a good idea, then it separates the implementation from the sort of abstract part that makes everything tick, and possibly allows modularization of the display server and easier replacement of components or even the whole display server.

However, at the start of everything it makes very little sense to have dozens of separate projects working towards the same goal, especially when they have to create their own custom protocol extensions for the things that aren't "standardized" yet. This is why we after all these years only Gnome is working on Wayland decently. KDE's support is crap, Unity is dead and XFCE is not making any strives towards Wayland let alone all those legacy projects building on top of Gnome 2 and GTK2.

[andreduartesp]

At this point, what still doesn't work with KDE on Wayland?

This is the official list from KDE https://community.kde.org/Plasma/Wayland_Showstoppers

[duby229]

Yes and no. Having a well-defined protocol at the core is a good idea, then it separates the implementation from the sort of abstract part that makes everything tick, and possibly allows modularization of the display server and easier replacement of components or even the whole display server.

However, at the start of everything it makes very little sense to have dozens of separate projects working towards the same goal, especially when they have to create their own custom protocol extensions for the things that aren't "standardized" yet. This is why we after all these years only Gnome is working on Wayland decently. KDE's support is crap, Unity is dead and XFCE is not making any strives towards Wayland let alone all those legacy projects building on top of Gnome 2 and GTK2.

I'll definitely give the Gnome devs props for getting their Compositor working with Wayland and getting everything else they needed implemented first. First come, first serve as they say...

However, Weston already exists and it has proven to be completely worthless as a reference because it does not implement the "everything else" part. Weston is not a complete compositor suitable for use in a modern GUI. At the very best you could shoehorn it on a kiosk or something.

Gnome is currently the only GUI with a compositor capable of supporting Wayland that is functionally complete. And by "functionally complete" I mean, we all know, Gnome is -designed- to be a stripped down and barely functional GUI. It needs at minimum a half dozen extensions for a reasonable desktop experience and those will almost certainly break on the next update... That's in addition to their attitude of "must ignore all users" they exhibit at every point... So it has also proven to be worthless as a reference.

The end result is that every single compositor that has tried and is trying -actually is- re-inventing everything that they need to create their own functionally complete compositor.

[andreduartesp]

Yes and no. Having a well-defined protocol at the core is a good idea, then it separates the implementation from the sort of abstract part that makes everything tick, and possibly allows modularization of the display server and easier replacement of components or even the whole display server.

However, at the start of everything it makes very little sense to have dozens of separate projects working towards the same goal, especially when they have to create their own custom protocol extensions for the things that aren't "standardized" yet. This is why we after all these years only Gnome is working on Wayland decently. KDE's support is crap, Unity is dead and XFCE is not making any strives towards Wayland let alone all those legacy projects building on top of Gnome 2 and GTK2.

GNOME support is good because they use non-standard protocols, like the clipboard, now Wayland has a standard protocol, and GNOME apps just don't work outside GNOME environment correctly, because they use a different protocol.

[oiaohm]

Yes and no. Having a well-defined protocol at the core is a good idea, then it separates the implementation from the sort of abstract part that makes everything tick, and possibly allows modularization of the display server and easier replacement of components or even the whole display server.

This is correct.

However, at the start of everything it makes very little sense to have dozens of separate projects working towards the same goal, especially when they have to create their own custom protocol extensions for the things that aren't "standardized" yet.

Except its not dozens creating their own custom protocol extensions. You have gnome based, QT based(KDE and others), wlroots based and libweston based. That is 99 percent of all you wayland compositors are in one of these camps. Of course everything in libweston has already been standardised. So there are really only 3 sources of non standard extensions to Wayland being gnome, QT and wlroots.

However, Weston already exists and it has proven to be completely worthless as a reference because it does not implement the "everything else" part. Weston is not a complete compositor suitable for use in a modern GUI. At the very best you could shoehorn it on a kiosk or something.

Except Weston is not just a reference.

https://github.com/wayland-project/weston

libweston exists for those who want to make a standard conforming Wayland compositor without having to re-implement a lot.

Gnome is currently the only GUI with a compositor capable of supporting Wayland that is functionally complete.

This has ignored all the wlroots based compositors.

The end result is that every single compositor that has tried and is trying -actually is- re-inventing everything that they need to create their own functionally complete compositor

This is not true no matter how many times you say it duby229.

https://github.com/swaywm/wlroots/wiki/Projects-which-use-wlroots

There are at least 36 different compositors that have decided to share the development of those parts with wlroots.

The reality like it or not duby229 there are roughly 4 different camps of Wayland compositors. Compositors owning to one of those camps does not re-invent everything they share with all the other compositors in the same camp as them.

Basically Wayland development is not as fragmented as it first appears. But there is quite a bit of disagreement over how the shared library between compositors should be done and this is why the 4 different camps.

There is also a lot more wayland compositors in existence than many would dream already. There are more Wayland compositors in existence already than the total number of X11 windows managers that have ever existed. Largest number are in the embedded space in like car entertainment systems based of libweston. This number would not exist if they were starting from scratch every single time.