KDE Plasma 5.21 Now In Beta With Much Improved Wayland Support

[bug77]

And people using Linux don't "own" it? As I know it's opensource and people can add features they miss. In fact, they do that - e.g. the security workarounds around X11, alternatives to Wayland and adding features to GUI toolkits. On the other hand, MS can own whatever they want, but it's for nothing if developers don't use it. (On the other hand on Linux, the one with biggest workforce wins, because their solution is developed the fastest and devs of alternatives lose desire to continue.)

I meant Microsoft own the whole stack. When they add signals (or whatever) to their DE, they can add signals processing to the toolkit in one go.
On Linux, you have to add the signals to X or Wayland (or both, but I think that rarely happens). If it's Wayland, you have to get the implementations to start emitting those signals. And then you have to teach both Qt and Gtk+ to handle them. Not impossible, in some cases it could be the same guys doing the work albeit having to work with several teams/projects. It's certainly going to take a lot more time to market.

[Ladis]

That's not the difference. The difference is Microsoft owns the toolkit the apps use, so they added the needed signal handling themselves.

And people using Linux don't "own" it? As I know it's opensource and people can add features they miss. In fact, they do that - e.g. the security workarounds around X11, alternatives to Wayland and adding features to GUI toolkits. On the other hand, MS can own whatever they want, but it's for nothing if developers don't use it. (On the other hand on Linux, the one with biggest workforce wins, because their solution is developed the fastest and devs of alternatives lose desire to continue.)

[bug77]

Windows handles this perfectly - supports both HighDPI apps (the older ones, like X11) and MultiDPI apps (the newer ones, like Wayland). On Linux, you have to choose between those. Means, on X11 you can't handle monitors with different DPIs (in older DEs there was a trick it sent an event the DPI changed and some apps responded to it, some needed restarting), on Wayland even apps which support HighDPI are rendered in LowDPI and stretched (blurry). On Windows, it renders HighDPI apps in the primary monitor's DPI and then stretches as a bitmap on other monitors (in a single-monitor setup you don't know the app is old - it's still crisp). Fun fact: I read somewhere, maybe here on Phoronix, on Fedora/Wayland it uses that hack - it sends the correct DPI and the DPI-changed event like on X11 when you run Chrome/X11 via XWayland (so for users it looks correct, but requires knowing the app will respond to that X11 event).

EDIT: This is the difference between Windows and Linux. On Windows, they just added few more system events an app can respond to (plus the Compatibility tab in the app's properties to force one way or another). On Linux you have to rewrite all the drawing code in your app (or people making the GUI toolkits have to and you have to update your code to use the new version of the toolkit). This causes much faster adoption among apps on Windows than on Linux (especially maintaining 2 codepaths to keep X11 users supported). I understand the security reasons, but I believe there were ways on X11 to work it around (like those apps to separate X11 apps to own processes yet drawing them together on one desktop; Windows had similar issues - I remember all GDI resources, like brushes, were globally shared among all apps to fit in 4 MB of RAM - the minimum requirement for Win95).

That's not the difference. The difference is Microsoft owns the toolkit the apps use, so they added the needed signal handling themselves.

[Ladis]

Plasma under Wayland is mostly okay now. The Wayland showstopper for me is that anything running in Xwayland has blurry fonts on a HiDPI display which renders (literally) the whole concept of using a Wayland session completely unusable.

IIRC it's the same on Windows, am I wrong?

Windows handles this perfectly - supports both HighDPI apps (the older ones, like X11) and MultiDPI apps (the newer ones, like Wayland). On Linux, you have to choose between those. Means, on X11 you can't handle monitors with different DPIs (in older DEs there was a trick it sent an event the DPI changed and some apps responded to it, some needed restarting), on Wayland even apps which support HighDPI are rendered in LowDPI and stretched (blurry). On Windows, it renders HighDPI apps in the primary monitor's DPI and then stretches as a bitmap on other monitors (in a single-monitor setup you don't know the app is old - it's still crisp). Fun fact: I read somewhere, maybe here on Phoronix, on Fedora/Wayland it uses that hack - it sends the correct DPI and the DPI-changed event like on X11 when you run Chrome/X11 via XWayland (so for users it looks correct, but requires knowing the app will respond to that X11 event).

EDIT: This is the difference between Windows and Linux. On Windows, they just added few more system events an app can respond to (plus the Compatibility tab in the app's properties to force one way or another). On Linux you have to rewrite all the drawing code in your app (or people making the GUI toolkits have to and you have to update your code to use the new version of the toolkit). This causes much faster adoption among apps on Windows than on Linux (especially maintaining 2 codepaths to keep X11 users supported). I understand the security reasons, but I believe there were ways on X11 to work it around (like those apps to separate X11 apps to own processes yet drawing them together on one desktop; Windows had similar issues - I remember all GDI resources, like brushes, were globally shared among all apps to fit in 4 MB of RAM - the minimum requirement for Win95).

[JackLilhammers]

Yes, I know. The work is being done, it's only a matter of time. I'm quite confident that for 2022* most of the pieces will be in place. Also thanks to the work on Gnome.
*The next LTS release of Ubuntu, and Neon

[darkbasic]

Then you can use X for another year, as you did for the last 20 :'D

PS: it's been my desktop too, albeit not for that long

Development on X stalled and some things are just impossible to achieve, like per monitor scaling.

[JackLilhammers]

Because KDE has been my main desktop environment for the past 20 years?

Then you can use X for another year, as you did for the last 20 :'D

PS: it's been my desktop too, albeit not for that long

[f0rmat]

It is really good to see that KDE is continuing its focus on polishing what it has as opposed to creating new k-whatevers. The KWin/Wayland work is good and the Plasma System Monitor looks good (ok, new, but building on and extending things that were mostly in place). Krunner is a gem and the Kate improvements look pretty good. However, I will not be using the new kickstart menu - looks too much like old Windows to me. The current kickstart menu is one of those little additions that I really like about KDE - but that is personal preference - and I am glad that it will still be available.

I am on KDE Neon and for WIW, I have noticed steady improvements in screen tearing in multiple monitor setups of different aspect ratios during booting, login and logoff, and screen locking.

[f0rmat]

Great improvements !

I wish now the KDE Applikations are Krenamed Korreckly instead of stupid heterogenous names. (ex to follow : gnome & deepin)

Typo - I kwish now the KDE Applikations are Krenamed Korrekktly.... And when will the rename it from better GTK support to KGTK?

[f0rmat]

Glad to hear I am not the only one who has to force shutdown his PC every time Actually, when I shutdown I don't do it daily so my packages usually get upgraded in the meantime. My guess is that package upgrades cause the shutdown issues ...

I have filed at least one bug report on that. (I use KDE Neon). I have noticed big improvement - but it is Neon which, while on Ubuntu LTS, is still a kind of tolling KDE desktop.