The double-click speed setting returns, and now lives on System Settings’ General Behavior page. Before you ask why it’s not on the mouse Page, it’s because it affects touchpads too and that has its own page, and duplicating the setting on both pages seemed messy and ugly
As long as the value is synced, I can’t imagine how it would be bad to have in both pages; especially since that’s where a user would expect to see it.
There’s nothing wrong with multiple ways to find a common setting
I think the best solution is to have a… Link? To the general setting.
Having duplicated settings across multiple settings page is something that I think is an issue. Cause it isn’t obvious to the user if the setting is actually shared between the two pages or if it has two different options with the same name. It also doubles cognitive load to the user, as if they have a Touchpad and Mouse they need to remember both pages have the same setting.
A link is more of a way for the designers to tell the user “Hey, we know what you are trying to find, but it is in another place”
Great news regarding the reorganisation of System Settings. I am skeptical about the sorting however? Why put “Internet” first and “Appearance” so low? Seems to me the later is often the first thing people look for in Settings (and thus often first, or near the top, in most settings).
It might also just be what people are familiar with on other systems. On iOS, macOS, Android and windows, the wifi settings are usually at the top. So it makes sense for KDE to do the same.
My impression was that it was more common to have stuff like “Appearance” first, but you seem to tbe right. At least on my Android phone, network is the first item indeed. I guess I’m getting old!
Haha, I guess Wifi just requires you to go into the settings more often than something like appearance, which you usually set, and then rarely come back to.
no more frames within frames! Instead Breeze-themed apps adopt the clean design of modern Kirigami apps, with views separated from one another with single-pixel lines!
Does this talk about that little blue square that is inside of dolphin where the folders reside?
I get into phases where I use Activities, and I like the workflow, but then I forget about it for a while. I like having the separated workspace with no other thing showing up in the taskbar, but moving applications between the activities is a pain.
I’d like to see it stay but I don’t have the knowledge to maintain it, so I guess I’m at the mercy of the KDE team’s willingness to keep it on life support.
@ikidd@leopold
I use 4 work spaces & organize by my own system/categories as I start opening stuff after a weekly restart, a couple of vivaldi instances, firefox all with their own email & download locations
No special setup beyond me remembering my own scheme, easy to move stuff between work spaces
Wayland+Plasma 5.27 feel pretty close to usable, so I’m hopeful that with Plasma 6 I can finally just pick Wayland and stick with it and not have to back to X11.
If Nate thinks that wayland only on Plasma 6 is the way to go then I feel like we as a user should trust him.
Currently I use AMD hardware and for me KDE + Wayland is fantastic experience. Some crashes here and there, with which I’m fine with.
My brother is running Fedora Kinoite + Wayland with Nvidia and he is total noob when it comes to Linux. He is happy and never complained about his system.
So, I would only assume for normal use case wayland is already in good shape currently. It is only going to get better with plasma 6.
If Nate thinks that wayland only on Plasma 6 is the way to go then I feel like we as a user should trust him.
Well… that is not what he is saying. X11 will be supported for a long time still. In fact KDE has not even set a deadline for ending support for X11^*^. It will definitely not end with the release of Plasma 6.
The point is that not adapting software to Wayland is a mistake. It may be a pain, but X11 is virtually abandonware. The developers have moved on (to Wayland) and there are no new versions coming out – unless someone forks it, of course, but that would probably be another mistake, as the codebase is an unsustainable mess.
This implies that, yes, when most software projects have got their applications working on Wayland, X11 will be phased out as a platform Plasma works on, but there is no date for that yet.
– ^*^ Other projects are less coy. Fedora is considering removing support X11 from their very soon, maybe in their next releases. This is what sparked the discussion. Not KDE.
I finally found my use case for activities - switching between work and personal stuff. Having virtual desktops isn’t enough to separate the two for me, but activities does the job really well. Would miss the feature if it goes the way of the Dodo in the future.
I will preface that Xorg is obviously an unmaintainable mess of legacy decisions and legacy code, and I have both a machine that runs Hyprland and a machine that usually starts Plasma in Wayland mode so the Wayland situation getting to be more-or-less adequate with persistent irritations here and there… but Wayland is trauma-driven-development. It’s former xorg developers minimizing their level of responsibility for actual platform code, but controlling the protocol spec, and in the position to give up on X in time with their preferred successor.
Essentially all of the platform is being outsourced to other libraries and toolkits, who are all doing their own incompatible things (Which is why we have like 8 xdg-desktop-portal back-ends with different sets of deficiencies, because portals were probably designed at the wrong level of abstraction), and all have to figure out how to work around the limitations in the protocols. Or they can spend years bikeshedding about extensions over theoretical security concerns in features that every other remotely modern platform supports.
Some of that outsourcing has been extremely successful, like Pipewire.
Some attempts have been less successful, like the ongoing lack of a reasonable way to handle input plumbing in a Wayland environment (think auto-type and network kvm functionality) because they seem to have imagined their libinput prototype spun out of Weston would serve as complete generic input plumbing, and it’s barely adequate for common hardware devices - hopefully it’s not too late to get something adequate widely standardized upon, but I’m increasingly afraid we missed the window of opportunity.
Some things that had to be standardized to actually work - like session management - have been intentionally abdicated, and now KDE and Gnome have each become married to their own mutually-incompatible half solution, so we’re probably boned on that ever working properly until the next “start over to escape our old bad decisions” cycle… which, if history holds, isn’t that far away.
We’re 15 years in to Wayland, and only in the last few years has it made it from “barely a tech demo” through “Linux in the early 2000s” broken, and in the last year to “problems with specific features” broken … and it is only 4 years younger than the xf86->xorg fork.
Your issue is you’re assuming all things must be standardized in a monolithic fashion.
The whole point of Wayland is that monoliths are bad in an environment as diverse as the Linux desktop.
Either libinput will be improved or it will be replaced as needed.
I’d argue portals are deficient because Wayland implementations in general are not complete. An org like KDE or GNOME has a fair bit of man power but they’re still in a position where they need to keep X11 functional and they need to carry forward decades of features. Even if Wayland was flawless from the onset that’s a huge undertaking.
Wayland is one part of what needs to be a collection of specifications, but the point is to have a specification instead of an implementation. You can actually have implementations that make different trade-offs and optimize different use cases that way.
That doesn’t prelude something like mir or wlroots acting as a base layer for desktops that don’t want to build up from the specification … but it does allow KDE to write a compositor that does exactly what KDE needs/wants … instead of the X11 mess where you can “turn the compositor off” which results in effectively two classes of desktop, one of which is used for gaming, the other for general desktop use … or any of its various other issues.
They don’t have to be specified in a monolithic fashion, but some things - like the input plumbing and session management examples I made - do have to be specified for for software to work when running under different compositors. FD.o basically exists because we already learned this lesson with other compat problems, and solved it without putting it in the X monolith - it’s why things like ICCM and EWMH happened; there were more details than were in the existing APIs that everyone needed to agree on to make software interoperate.
Competing implementations are great, but once you have significant inertia behind competing implementations which are not compatible or at least interoperable, you’ve fragmented the already-small Linux market share into a maze of partially-incompatible micro-platforms. We’re not going to have compositing and non-compositing, we’re going to have 3ish (KDE/Qt [kde], Gnome/Gtk who aren’t even doing documented protocols, and Everyone else - mostly [wlr] extensions) incompatible sets of protocols for basic functionality.
Looking at the slow bitter process to extend or replace components once implementations that rely on them exist, that’s not something to count on. Remember how it took 15 years of contention to eventually transition to D-Bus after CORBA/Bonobo and DCOP? That’s whats about to happen with things like the incompatible gtk and qt session management schemes. And that resolution was forced by the old HAL system using it, not the other parties involved getting their shit together of their own accord.
One place we’re about to see innovation is wayland-stack-bypassing workarounds. Key remapping is currently in that category, the wayland protocols suite punted… so instead, keyd sniffing all the HID traffic at the evdev and/or uinput layer and outputting the rule-edited streams to virtual HID devices. That one does have a certain global elegance (works on ttys!), but it’s also layering violations with privileged processes.
I’m not going to say that there haven’t been balls that have been dropped on some things. Like, we should’ve come out of the gate with a protocol for remote desktop access as an example.
However, when all these X11 developers say it’s time to move on, I’m inclined to believe them.
We’ve already had the fragmentation between different desktops on various things, dbus APIs as an example have often been KDE or GNOME specific. It’s been a long standing complaint really. And well, as much as I’m sympathetic I think we get more from flatpak than we lose from Wayland. There are going to be specific niche programs that need to deal with specific APIs but in general, I think it’s easier than ever to ship “one package” and have it just work where you need it to.
Based on the inertia that wayland has I’d be shocked if it takes 15 years for one or two dominate APIs for various missing pieces to emerge with one becoming the standard.
So we’re calling just doing one thing “trauma-driven-development” now? Yeah, Wayland doesn’t do everything Xorg does. That’s a good thing. Xorg is a dying, dysfunctional mess because it does a thousand different totally unrelated things and nobody understands all of them and how they’re all tied together. We’re probably going to run into the same problem again eventually with systemd. Feature creep is toxic for open source software.
Wayland has problems, but not being X12 isn’t one of them.
One problem that has long plagued X11 is that any app can snoop on any other app, including things like keystrokes and displayed information, even from within containers like Flatpak. (This is understandable, since it was designed at a time when spyware was rare, so there was no need for isolation more fine-grained than the user level.)
IIRC, Wayland didn’t address that problem in its early days, but in these modern times of surveillance capitalism, I suspect it has been getting more attention. It would be nice to see it solved.
The risk existed but did it plague X11? I never heard about any app logging keystrokes and sending theme somewhere. Where there any attacks using this? I don’t think normal uses had to worry about it.
Yes, and it still does. Practically every X11 installation is vulnerable.
(If you’re nitpicking my use of the word plagued, though, note that I am talking about the vulnerability, not the exploit.)
I never heard about any app logging keystrokes and sending theme somewhere.
That’s because of a variety of external factors, including:
X11 desktops aren’t common enough to be priority malware targets, yet.
People who run only open-source software typically get it from trustworthy channels, like their OS distro’s package repository.
Devices likely to attract malware, such as game consoles and mobile phones, have avoided X11. (Android phones and Steam Deck are examples.) This is no accident; lack of app isolation was a factor in that decision.
I don’t think normal uses had to worry about it.
We’ve been lucky so far, in that our circumstances have kept us mostly safe. However: Linux malware is on the rise. Commercial games, both on their own and through anti-cheat systems, are making opaque software more common on our desktops. Flathub is working on paid apps, which could likewise create malware opportunities that weren’t there before. The Epic Game Store has already been caught collecting data from other apps, so the intent is clearly present already.
It’s generally just a matter of time before exploitable systems become exploited systems. We would do well to close the door on unauthorized key logging, clipboard snooping, screen scraping, and input injection.
And all the arguments are like this. “It’s good to use it”, “it has features”, “it’s better code”. But it’s never “it has essential features that people need”. Because it doesn’t. If it did people would use it.
You have misunderstood me. I don’t use or promote Wayland, mainly for the very reasons you just listed. But I do recognize that it has the potential to solve real problems that are deeply embedded in X11. If/when it gets there, and fixes various deficiencies that it has today, I expect I will have a good reason to switch.
But it’s never “it has essential features that people need”. Because it doesn’t. If it did people would use it.
Actually, I believe it does have such features for people with certain hardware setups. I just don’t happen to have such a setup.
It does for me. For some reason my touchpad has really high scroll sensitivity with libinput. It’s borderline unusable. The only desktop environment that exposes the ability to change this sensitivity is plasma Wayland. AFAIK there’s technical reasons it can’t be done on xorg without hacky workarounds. This is the killer feature for me.
In addition both plasma and gnome only have 1:1 touchpad gestures on their Wayland sessions. Obviously I could use third party tools for trackpad gestures under x11 but those aren’t 1:1.
Also while I’m aware that fractional scaling on Wayland is a mess and hacky but I still find the fractional scaling implementation on KDE Wayland to be the best, followed by KDE on xorg. I need fractional scaling for things to be appropriate sizes on my laptop screen.
For my desktop I still use x11 because of nvidia but I would definitely benefit from the multi monitor improvements under Wayland since I have two monitors of differing refresh rates and it causes issues.
Nope, I also use it for many of these things. They’re not alone by a long shot.
If you want to continue to use X11, you are free to simply not update your machine any further. It’s unlikely you value security, so this shouldn’t be an issue for you.
mixed DPI scaling (can drag a window from a 1x screen to a 1.75x screen and have it look correct on both at the same time, even when halfway across each)
Mixed refresh rate (my center monitor is higher refresh rate than my side monitors, X11 just baselines all monitors to the lowest common denominator).
Mixed variable refresh rate (center monitor is VRR capable, side monitors are not).
HDR support soon (already exists in GameScope).
Mixed HDR/SDR output across monitors
Performance:
Lower resources
Smoother operation (can be felt in mouse cursor movements, window drags, composited animations, etc)
Better VR headset isolation compared to X11 (allows the headset to run separately and not interrupt regular monitor layout, and also lets it run freely at the correct refresh rate)
Other:
Better security between apps (yes I actually use this and count it as a feature)
App video isolation leads to pipe wire functionality, which is a bonus and makes OBS work better overall
I know for a fact I’m forgetting something because this list was longer the last time I wrote it out, but I think you get the point.
Maybe a while ago that was true. But there’s so much cool stuff that KDE devs are spearheading with Wayland.
For example, You’ll be able to reboot the window server without ending your session and losing your app state! They’ve demonstrated being able to swap between GNOME, KDE, Sway, and other WMs without logging out or crashing apps. This could also be used for swapping active GPU configurations without relogging, which would make Gaming laptops way less shitty to use.
Wayland can also store window state to disk, which isn’t possible on X11. Another useful feature that could allow for more fluid hibernate and reboot behaviour.
Touchpad gestures! You need a lot of dev effort to get them working on X11 but on Wayland it’s very fluid.
Wayland is also partly why there’s been new effort to standardise the desktop experience on Linux with stuff like XDG.
For the end user, X11 is fine. You don’t need to particularly care how your windows are drawn. As an app or desktop dev you’ll be way more empowered to build a next generation desktop experience with Wayland, in a way that X11 just wasn’t able to support because of its underlying design.
But that’s also why the change can’t come from begging end users to migrate: we have to rely on distros dropping support for X and making Wayland the default.
Well, it’s a big upgrade underneath. They’re moving from qt5 to qt6. Tons of fundamental wayland fixes with the new toolkit/framework. You might be right that it’s not that dazzling of a visual overhaul, but it’s a mature product. We need more polish than overhaul
The migration to Qt6 and the work being carried out on Wayland, which is all going into Plasma 6.0, is going to allow massive changes that will be introduced over the 6.x series. There are some pretty cool features in 6.0, but the bigger changes will come over the next few point versions.
It is unlikely you will see any of these updates in Plasma 6.0, as they are more proof of concepts than finished, tried and tested features. But you will see them introduced over the next versions in the 6-x series.
Are you a KDE user? I switched from Gnome 3 when Plasma 5 was new, the very moment it seemed close enough to finished to expect reasonable stability. It was a huge departure from KDE4, and after trying literally every other DE to find happiness away from Gnome (that's all I'm going to say about that) over the course of several years, it was such a welcome relief.
Plasma 5 was not only a life preserver for folks bailing from Gnome, it also showed they'd learned from their own mistakes with KDE4, which many users felt was just as much a trainwreck as Gnome 3.
There's a lot going on under the hood with the change to QT6 as noted, and that alone merits a version number change, IMO. I haven't tracked a whole lot of specific features, but I know there are a lot of wayland refinements and HDR support coming, and I'm doubtful that the many pointieststick blogposts have been doing nothing but writing about bugfixes and menu changes, even if I haven't read every single one of them.
The general default look and feel maybe isn't being radically changed, but this is Linux, and more importantly KDE; we're all about theming and customization anyway, right?
Most importantly they aren't throwing out the baby with the bathwater. They did it (intentionally or not) with 4, and then (in my perception) they were forced to do it with Plasma 5 because of KDE4.
After living through the transition from Gnome 2 to 3, and KDE 3.5 to 4, then feeling the relief when Plasma 5 just absolutely crushed it, I'm very happy to see them upgrading the undercarriage and making things generally better instead of building it all from the ground up again.
@be_excellent_to_each_other@leopold@Fizz I’m actually 100% happy with just bugfixes. KDE is my choice, but, I mean, its still a fairly buggy desktop. It’s great, all it needs is the masses of bugs fixed, anything that does that is good. That’s all it needs.
Yeah I understand it’s a lot under the hood, but people seem to anticipate it like it’s the best and most exciting thing since the second coming of sliced bread. I kinda don’t get it. But it’s good that it’s coming along. I probably won’t even notice a difference.
because those two things are pretty much what Plasma needs the most at this point. the two most common complaints about Plasma are that it’s buggy and that it’s ugly.
Wayland isn’t perfect, but it’s definitely getting there.
I think one of the biggest migration problems is that things have to move from the windowing system to the desktop environments, and they’re slowly adapting to it.
Are you using the Jerboa client? I think they recently introduced an option to open links in a private tab which is on by default for some reason. It confused me too until I found the setting.
pointieststick.com
Top