KDE Saw More Wayland Fixes This Week, Other Changes

[acobar]

X was being used as a dumb framebuffer though, window managers already did their own thing and bypassed 99% of the cruft. Wayland is a statement of that reality. GNOME and KDE are fundamentally different, despite the visible result--interactive graphical elements displayed in a screen--being similar.

I don't know from where people get these cabbalistic numbers, but they aren't true. Granted many parts of X became obsolete with time, but it was to be expected anyway, as hardware changed a lot over all the years and so did GUIs. Exaggeration brings nothing to the discussion. And lets disagree about Gnome and KDE, they are, fundamentally, very alike, only with different priorities and interpretations about what is the best way to present a GUI.

For a "proper library" there's wlroots, but none of the big names are going to use it. If Xfce ever joins the Wayland party, I bet they'll be backporting whatever GNOME is doing at the moment, since they use GTK.

wlroots was late, perhaps, too late in the game. This should be something present on the beginning and backed by all important players. Anyway, this ship has sailed a long ago.

[angrypie]

I don't know from where people get these cabbalistic numbers, but they aren't true. Granted many parts of X became obsolete with time, but it was to be expected anyway, as hardware changed a lot over all the years and so did GUIs. Exaggeration brings nothing to the discussion.

Counter-exaggeration without actual numbers doesn't help either. You didn't prove anything.

And lets disagree about Gnome and KDE, they are, fundamentally, very alike, only with different priorities and interpretations about what is the best way to present a GUI.

They use completely different toolkits (Qt vs. GTK), different languages (QML/C++ vs. C/JS), different shell architectures (Plasma + Kwin + other kdaemons communicating through IPC vs. GNOME Shell being a Mutter plugin), different extension mechanism (Plasmoids, i.e., actual standalone applications vs. live-patching the shell) and different design decisions (minimalism vs. endless customization). They are fundamentally, intrinsically different from each other. This is not a matter of opinion.

wlroots was late, perhaps, too late in the game. This should be something present on the beginning and backed by all important players. Anyway, this ship has sailed a long ago.

Weston is the reference implementation, has been present from the beginning and is developed by Red Hat. This is likely what GNOME and KDE based their implementations on.

[Aryma]

acobar KDE chose to stay away from early Wayland development. KDE chose to ignore the design principles from the reference compositor. KDE chose this mess.

kwin "KDE" compositor is still a mess even in X11 there some alternative but I hate how KDE dev didn't focus on Wayland or kwin and keep bring new project like KDE in mobile even after they saw what happened to ubuntu mobile or any Linux mobile except android

[Charlie68]

There is no reason to be in a hurry, there are things in Wayland that are far from ready.
For example I asked Plasma developers why application startups don't have any animation and the answer is that at the moment it is not yet clear how to implement it in Wayland. There should be meetings with dev waylands, in order to have a single implementation. Then Wayland has a big problem on notebooks, where tap-click and many devices are ultra-sensitive, no GUI at the moment helps people solve this problem.
So I don't think we need to be in a hurry, also because the Plasma desktop has a much more complicated GUI than Gnome.
There is no reason to change something that works well to something that won't work well.

[Thaodan]

Counter-exaggeration without actual numbers doesn't help either. You didn't prove anything.



They use completely different toolkits (Qt vs. GTK), different languages (QML/C++ vs. C/JS), different shell architectures (Plasma + Kwin + other kdaemons communicating through IPC vs. GNOME Shell being a Mutter plugin), different extension mechanism (Plasmoids, i.e., actual standalone applications vs. live-patching the shell) and different design decisions (minimalism vs. endless customization). They are fundamentally, intrinsically different from each other. This is not a matter of opinion.



Weston is the reference implementation, has been present from the beginning and is developed by Red Hat. This is likely what GNOME and KDE based their implementations on.

QML is QObject plus JS and Markup. GNOME has also GObject bindings for JS. The major difference excluding the different object systems is that QML has a markup modeled after MVC.

[Thaodan]

acobar KDE chose to stay away from early Wayland development. KDE chose to ignore the design principles from the reference compositor. KDE chose this mess.

So did GNOME? Did you ever had GNOME Shell crashing with all its plugins? GNOME has shell plus composositor in one.

[caligula]

It's probably what's pushing SDDM to revive ancient Wayland patches again after years of doing nothing in that area.

Isn't SDDM pretty much dead? I visited the github page. There are only 10 non-translation related commits this year. If you only consider the useful commits that add/change functionality, there's like less than 1000 LOC of changes during 2019-2021.

year LOC
2013 25744
2014 16563
2015 5802
2016 1982
2017 6595
2018 1206
2019 533
2020 1322
2021 241

[angrypie]

So did GNOME? Did you ever had GNOME Shell crashing with all its plugins? GNOME has shell plus composositor in one.

I know it's far from ideal from a robustness perspective, but inter-process communication adds latency, specially to a DE/WM that's supposed to deliver a smooth desktop experience.

If they were to split GNOME again into DE, shell and session manager (for Wayland sessions) that'd undo all performance improvements from the past 3 years or so.

[caligula]

I know it's far from ideal from a robustness perspective, but inter-process communication adds latency, specially to a DE/WM that's supposed to deliver a smooth desktop experience.

If they were to split GNOME again into DE, shell and session manager (for Wayland sessions) that'd undo all performance improvements from the past 3 years or so.

Maybe the architecture can be designed in a way that supports robustness on a coarse granularity? For example, if the shell hangs or crashes, would be nice if you could reconnect to clients. The most annoying thing in GNOME is if it crashes, you end up in gdm, but can't log in. You'll need to log in via a VT, kill the user session systemd / gnome shell, then try logging in again.

[oiaohm]

There is no reason to be in a hurry, there are things in Wayland that are far from ready.
For example I asked Plasma developers why application startups don't have any animation and the answer is that at the moment it is not yet clear how to implement it in Wayland. There should be meetings with dev waylands, in order to have a single implementation. Then Wayland has a big problem on notebooks, where tap-click and many devices are ultra-sensitive, no GUI at the moment helps people solve this problem.
So I don't think we need to be in a hurry, also because the Plasma desktop has a much more complicated GUI than Gnome.
There is no reason to change something that works well to something that won't work well.

This line of arguement needs to stop yesterday. This is head in sand stuff.
1) X11 on bare metal is lacking features required for proper HDR and Hidpi and security.
2) X11 server by x.org that is you default Linux x11 server for bare metal has not had a working maintainer for years.
3) Redhat Enterprise Linux 8 default interface is Gnome Wayland this is from 2019 this means Redhat developers only have to provide support to X11 on bar metal until RHEL7 end of life June 30, 2024 extended support by Redhat does not cover graphical. So we are under 3 years to Redhat pulling there developers completely out of X11 on bare metal.
4) AMD and Intel are not putting up a Maintainer this time for x.org. This is why Redhat has put up a maintainer for Xwayland that is X11 under Wayland.
5) Nvidia has never put up a maintainer to x.org for bare metal so they are a wild card with the funding that they could but this is unlikely.

So yes there is a need for a hurry to migrate to Wayland as it possible that next year released distributions will not have X11 bare metal either due to the fact it possible that Nvidia might at long last release a driver that can properly work with Wayland. At worst case we are under 12 months until no more X11 server on bar metal so no more xfce.... and other windows managers and de that have not done the work to get to Wayland.

Input issues are not a wayland problem at all. In fact wayland compositor should not be addressing input device problems.
https://wayland.freedesktop.org/libi...ce-quirks.html

Input problems are a libinput problem and libinput takes quirks files generically as in a quirk files fix X11 x.org server on bar metal and all Wayland compositors from one file. Yes that tap-click and many devices are ultra-sensitive this problem should be handled by libinput. Libinput is in need for a generic GUI for quirk file adjustment. Yes you are right there is a missing GUI here but its not a Wayland only problem its a generic libinput problem.

There is a common problem with people blaming stuff on Wayland that when you look closer is not Wayland at all but some decanted sub component that is shared between X11 and all Wayland compositors. Yes we are also seeing wayland compositors address items that they should not be like input device issues we need to get parties to in fact work with each other on core parts like libinput not have more debates on how wayland needs to change in lots of these cases. Yes items like input device issues are not inside the scope of the wayland protocol and what wayland it self should be dealing with but is inside the scope of what libinput is.