KDE Plasma 5.20 Released (phoronix.com) 45
KDE's Plasma 5.20 is now available, bringing a bunch of refinements as well as some larger features. Some of the KDE Plasma 5.20 highlights include (via Phoronix):
- Numerous fixes to the KWin window manager / compositor including a number of Wayland fixes. Among the Wayland work in Plasma 5.20 includes Klipper support and middle-click paste, mouse and touchpad support nearly on par to X11, window thumbnails in the task manager, crash fixes, and more.
- Improved notifications.
- Different redesigns and additions to the KDE System Settings from SMART monitoring to better looking interfaces.
- Redesigned on-screen displays.
- Various tack manager and system tray improvements. More information about KDE 5.20 is available here.
- Improved notifications.
- Different redesigns and additions to the KDE System Settings from SMART monitoring to better looking interfaces.
- Redesigned on-screen displays.
- Various tack manager and system tray improvements. More information about KDE 5.20 is available here.
In 2020 (Score:4, Funny)
mouse and touchpad support nearly on par to X11
Well done, lads! Keep up the good work!
An explanation of Wayland would be good (Score:4, Interesting)
As I understand it it is all about "Compositing" which as far as I can tell means that instead of sending high level commands such as writing text in some (missing) font in X with Wayland the client only sends bit maps to the display.
X had networking in its core -- to support X-Terminals over a moderate speed network to a shared computer. And not to load down that shared computer. So it had to use high level commands. II am guessing that Wayland would not do that. (X should run fine over the modern internet.)
Maybe for networked computing HTML 5 replaces X? I mean, X lacks JavaScript...
(Or maybe an X-like protocol should replace HTML 5 -- do most of the thinking on the application end, not the display.)
But maybe HTML 5 also replaces Wayland? If all UI is done with HTML5 the only thing that ever needs to talk to the real display is a browser which can be done in an ad hoc manner.
Compositing: basically yes. (Score:5, Informative)
The whole idea behind Wayland is to be a successor of X11, but with all the backward compatibility thrown away and restricted in a tiny "XWayland" separate server. And from the ground up though in modern terms.
Basically the same idea as the shift between OpenGL 4 and Vulkan.
One of the subject is indeed "compositing" (But it's not the only one. Other stuff include cleanup in the gazillion of legacy input APIs and concentrate on libinput.).
As I understand it it is all about "Compositing" which as far as I can tell means that instead of sending high level commands such as writing text in some (missing) font in X with Wayland the client only sends bit maps to the display.
Basically yes. But there are nuances.
- Modern X11 also do compositing, and a lot of modern X application also do compute their own bitmaps and send them over to X or even draw them in OpenGL.
- So there isn't much difference in a modern application running on a modern XServer or on Wayland.
- The difference is one of implementation: on modern X Servers this is done with extensions and patches that are built upon other extensions and patches. "It's turtles all the way down". Down to a base that was designed to send drawing commands, over a network connection (because shared libraries weren't a thing back then).
- Wayland is a new implementation that only does modern compositing.
X had networking in its core --
(because shared libraries werent wide spread back then. comunicating over a network socket with a central server was the most cross-platform way to avoid duplicating giant static graphical windowing libraries in every last app)
to support X-Terminals over a moderate speed network to a shared computer.
It's a "happy consequence" of using sockets. Not the primary target. The primary reason for network was the lack of shared libraries on some of the target platforms mentionned above.
So it had to use high level commands.
...actually, the chronological order is the other way around:
The use of high level commands comes from the fact that nearly all other graphical library backthen offered high-level primitives, and even the hardware that accelerated drawing, did accelerate some drawing primitive. (Think even examples as the PGC on IBMs [wikipedia.org]). If you though about a graph library, you tough about drawing lines, boxes, circles, rounded boxes [folklore.org], etc.
The concept of blitting bitmaps around came much later. Only when machine had enough CPU and RAM and video ram so that individual apps could handle their own internal virtual screens.
And X's problem is that by the time Compositing was a thing, it had already a couple of decade of legacy API.
(X should run fine over the modern internet.)
Actually, not quite.
Because most modern application rely on modern compositing, which usual counts on stuff like shared memory and openGL.
If you try this over an internet connection, it's going to suck badly -- you'de be basically streaming raw X bitmaps that you would be blitting. (And you might need to support stuff like AIGLX, accelerated indirect GL - streaming the GL commands over network)
The only reason it's somewhat functionnal (-ish) is because:
- Modern internet connection (think Fiber-To-The-Home) have decent speeds (symmetric e.g.: 1Gpbs)
- SSH has compression capabilities.
Basically, it kind of works, but that's more to do with the miracles of modern networking than with some 35-years old part of the API that nobody uses any more.
II am guessing that Wayland would not do that.
Again it's a bit more complicated.
The point of Wayland is to remove all old unused API. So there's no high le
Re: (Score:2)
I mean it wasn't just a 'happy accident', back then you had a model for text-based systems with multiple VT terminals wired from different rooms. That model carried forward for minimal graphical terminals so that you could share that system with 64MB of ram and 540MB hard drive that took up about 16U and cost so much you couldn't begin to risk a common user damaging it.
But yes, X primitives never evolved beyond what you would see with a basic Xaw application and as such have been ignored by modern applicati
Re: (Score:2)
I see nothing in Wayland that fundamentally improved upon X, but several features get lost, including forward and backward compatibility and network transparency. And the stuff X has and Wayland does not is the stuff needed to compatibility. Moving this into XWayland does not make it go away while only solving compatibility in one direction. Of course, the plan it too break compatibility eventually and this is really stupid. X compatibility was a major strength of the ecosystem which spanned far beyond Linu
Re: (Score:3)
Having used remote X11 back in the 1990's and early 2000's I think the growth of Multi-screen systems had put a near end to using X11 in that way. X11 over a network is slower then say RDP or VNC. As well based on your local XServer setup you can have a wide range on how well the windows rendered on your Workstations. Then combined with most apps trying to modernize their GUI so they don't look like what you are running is 30 year old software, that means X11 is sending over a lot of extra data, some of
Re: (Score:2)
Wayland is designed to facilitate efficient compositing, being a sm
Re: (Score:2)
I do not see what you mean by "lashed onto an API not designed for it". Extensions work fine for extending X. And the baggage is needed for backwards compatibility. I do not see how an unused extension would degrade desktop experience. (I use X and my desktop experience is fine.)
Splitting windows manager, compositor, and server may indeed lead to additional context switches, but one you could also combine them in one program. There was not reason to re-implement everything from scratch in an inferior way,
Re: (Score:2)
The general consensus amongst X11 devs is the protocol is too broken to fix without breaking it. And if you're going to break it, then it's not X and you may as well do things properly from scratch.
A
An explanation of X extensions would be good (Score:2)
I have not directly programmed X for may decades but as I recall it basically had a bunch of async calls for things like writing a font, drawing a line etc. I presume there was one for drawing a bit map, or remembering a bit map and drawing it at several places. It was quite efficient at redraw (as is MS Windows) in that you got a message to just redraw part of a window if needed. And of course, the window manager was just another client which maybe was a bit too clever.
But as I type to Slashdot, I main
Re: (Score:2)
X is a set of async calls to manage buffers, draw lines, and had support for fonts and other stuff. Some of this are not needed in modern clients but supported for backwards compatibility. In contrast to what Wayland fanboys on slashdot claim, no modern client is forced to use the old drawing API or similar to do stuff, they can just use the buffer APIs without any problem and combine this with modern extension where available. The idea that this old APIs somehow slow things done for modern clients is compl
Re: (Score:2)
And it's not a question of being a "fanboy". It's a simple matter of looking at the technical description & diagrams [freedesktop.org] and realizing which way of compositing is better and which is worse. Nothing prevents yo
Re: (Score:2)
I see that claim about the old drawing API slowing down modern apps quite often. While it is obsolete, it is not junk and needed for backwards compatibility. I know how modern apps work because I develop modern apps. In my opinion, separating window manager/ compositing manager from the server was actually a very smart decision. It allowed people to experiment with interesting window managers ideas (e.g. tiling). But of course, one could merge window manager and server those without breaking the X11 protoc
Re: (Score:2)
X is reduced to pushing pixmaps around and sending input events. Everything else is vestigial junk. And because X doesn't know anything about compositing or transparency, it has sprouted extensions that attempt to work within the confines of the protocol to do those things.
That's why the Wayland p
Re: (Score:2)
X has 30 years of cruft, patches on patches on patches on top of commands to draw lines and text from the first days of computing when the mainframe cpu had to draw every bit on the screen using analog. Your modern Xorg installation uses the same bitmap transmission and composting that wayland does.
Wayland was designed to duplicate how X currently operated without all the cruft. A few changes were made, but IMO none are significant. Afterall, Wayland was designed by the same people that maintain Xorg.
99% of
Good for KDE. X vs Wayland, not yet. (Score:3, Interesting)
KDE and new versions - good for them.
As for Wayland ... it's still in a lengthy alpha.
X-Windows was released in 1984 (yes, that long ago) and eventually reached version 11 (X11). It's bloating, huge, but works on all platforms. Wayland is newer, smaller, and better code (really) but not quite as stable.
"Less crashes" is not a feature. If more distributions would adopt Wayland and get it through beta and into production that would help it a lot.
Unfortunately, they have not.
So kudos to the K team, but leave Wayland out of it until you can get it solid. It just makes us all look like people who "tolerate" code that should never be given to grandma and uncle and the kids. If we can get some more distros to work on it and get it solid... it will kick the soon-to-be-old X11 to the curb.
Let's hope it's before W11.
E
Re: (Score:3)
Bloated and Huge for 1990's standards, is light and efficient in 2020 standards.
Re: (Score:2)
There is nothing bloated about X. There are some unused extensions, but this is neglectable.
Re: (Score:1)
There is nothing bloated about X. .
Yes, and Roseanne Barr is a skinny supermodel.
You tell the best jokes, Sir!
Oh my aching ribs!!!
Get someone who knows how to look at a codebase to look at X before you "opine" again.
Everyone's entitled to their opinion, but when it's based on knowing nothing and contrary to
clear fact, it's just a waste of everyone else's time. It's like not wearing a mask on a slashdot post.
Wear a mask.
E
Re: (Score:2)
I know the code base and your comment only makes it clear you have no arguments.
Re: (Score:2)
I would really hope distributions would drop Wayland and maintain full forward and backward compatibility for X. X works very well for me and is rock stable. I do see no reason to break compatibility with decades of software and give up a proven code base because of the "let's rewrite everything to make it better" crowd and some unsubstantiated FUD how bloated or broken X allegedly is. (and - after a decade - they still haven't produced something of acceptable quality).
I really like KDE Plasma (Score:2)
Only this announcement sounds really devoid of any technical content.
It should be a minor update...
Middle clicks (Score:2)
"Middle clicks" supported in Wayland.
that was a big blocker for me and my workflow.
I might finally give a go to wayland on my laptop (my phone is Wayland already)
So I am happy it got announced widely.
Re: Middle clicks (Score:2)
And you call this a release? Ah!
Full Announcement (Score:5, Informative)
You can find the full announcement at
https://kde.org/announcements/... [kde.org]
KDE is the original and best Linux on the desktop. We're a large community of open and free software developers making apps for app platforms but our flagship remains the Plasma desktop, lightweight and simple by default but powerful when needed it remains the best choice for Linux desktops with almost any use case.
Re: (Score:1)
Highlights: Fixes ! (Score:1)
Re: (Score:1)
Qt is GPL since 2000 (Score:5, Informative)
You might be remembering that KDE software uses the widget set Qt, which was originally non-free and then released under an impractical, GPL-incompatible license called the QPL. This ended in 2000 when Qt for X11 was released under the GNU GPL, with LGPLv3 added in 2009. The "demand money from developers" impression you got may have been related to a couple things:
1. It took a few more years for Qt for macOS and Windows to be released under the GPL.
2. The Qt Company (formerly Trolltech) has had a longstanding practice to sell exceptions to the GPL [fsf.org], at first for use in non-free software and then (after the LGPL switch) for software that runs on curated copyleft-hostile platforms, such as iOS and game consoles.
Re: (Score:2)
But will it support panning? (Score:2)
Use of "panning" improves my desktop productivity by about 20%, and I cannot forego that.
Cinnamon Flipped a Windows User (Score:1)
Re: (Score:3)
pre-mid 1990's I was an avid MS DOS user I hated windows. I use Desqview for multi-tasking in the early 1990's. early-mid 1990's I switched over to Linux. And I was really happy with it, I even got use to a windowed environment (after I upgraded to a computer with a new video card, graphics ran faster than text mode)
However by 2000 or so, Linux became humdrum to me, so I went on a Unix Kick, So after some stints with FreeBSD and OpenBSD, I settled on Solaris for the UltraSparc. Then I moved to Macs as OS X
Performance? Accessibility? (Score:1)
Re: Performance? Accessibility? (Score:5, Interesting)
I first tried KDE about ten years ago on a laptop that, for the time, was top of the line. The performance was terrible and I ditched it.
I dug that laptop out about a year ago and installed Linux because I needed a laptop and I keep finding reasons not to buy a new Macbook. First I tried elementaryOS, as it is my favorite. Even with the right Nvidia driver, it had some persistent display glitches. Next I tried Gnome. Once I customized it with all the extensions I wanted, it was just too slow. Next I tried MATE. It worked okay, but it is really showing its age.
I remembered that some posters here mentioned thar KDE had made some major improvements in speed. They were right. KDE is as polished as Gnome3 and as fast as XFCE. It can also be easily customized to work more like MacOS and less like Windows, which is important to me.
Nostalgia (Score:2)
Any way to get some classic window managers to work on modern distros? I'd love to have my work desktop running Sun's olwm or 4dwm from SGI. Yeah I know olvwm source is there and that dead 5dwm project but someone has to have something newer.
Meanwhile in GNOME 3.38 (Score:3)
Does it have.. (Score:2)
Re: (Score:2)
different backdrops for different virtual desktops (Score:2)