What do you think KDE should focus on for the next two years? - Call For Submissions

submitted by
edited

https://blogs.kde.org/2026/06/20/kde-goals-call-for-submissions/

We are not Adobe scumbags. We actually care about your input.

Please share your ideas:

👉 https://blogs.kde.org/2026/06/20/kde-goals-call-for-submissions/

40
75
1

Log in to comment

Hot Top New Old

I know this is a weirdo hope, but I personally would wish to see KDE take a more clear stance against LLM code submissions, and to move away from relying on systemd so much. But I suppose most regular users would prefer more tangible features and changes.

 reply
15
edited

Focus might be a bit much,
I only have a single feature wish, and that is to have file copy operation progress show correctly.
As it is, if I copy a few gigabytes to an USB stick, it very quickly shows as finished.
But it can take up to a couple of minutes before the operation is actually finished, and the stick can be unmounted and removed.

The easiest way to check I know of, is tom open a terminal and simply use sync. And it seems immensely primitive to me that I have to do that.

This is an age old problem for copying files that began to occur on PC systems way back around 1991, when write cache became a thing for disk operations. And honestly it makes me sad that this problem still isn’t solved now 35 years later. 😥

Otherwise I think KDE is doing great with their desktop, except I think it should just be called KDE desktop, and not that other thing they call it now.

 reply
23

I don’t think this is a KDE problem, but more the way Linux operates. I looked into this once and it’s basically because Linux considers the operation done when the source file is completely read and committed to the destination, but not actually written yet. I see this same behavior with my USB backup drives where something finishes but then I have to wait a minute or two when actually unmounting the drive. I think there’s a way to change this but I’ve never done it.

P.S. I just want KDE to make activities great again :(

 reply
19

Wow, I’m really glad this topic came up. As a recent convert from Windows, it’s still muscle memory for me to yank out a flash drive as soon as the copy dialog completes. (Yes, I know ejecting a drive first is still the proper thing to do on Windows, but skipping that has not been an issue once in hundreds of cases.)

 reply
10

A simple sync would show you when it actually finishes. However, it has system-wide effects. Perhaps KDE could lobby for a similar action to become available that is limited to e.g. a specific process id?

 reply
9

I would settle for checked-by-default “sync and wait” option. That way I can choose whether to cause a sync or not.

 reply
11

Often this is the correct pragmatic power user solution in UX design. Trying to solve it by default for everyone is much harder and will ultimately alienate some user.

But when people get bothered by an experience it is much easier for them to find the hidden setting that makes them happy again. It also preserves the existing experience, while allowing for greater customization in the long term.

Once a decent compromise is identified, that’s when it’s time to flip which setting gets to be the default.

 reply
7

My motivation for calling for it to be the default was that it’s safer (in terms of data).

Another UX principle is that of least surprise. I think it’s reasonable to assume that most users will expect the copy to be fully complete when the dialog closes, and that they will be surprised when their files are corrupted. Changing the behavior in the desktop to delay closing the dialog until any copying to removable media is complete should not be a controversial change.

We’re seeing an influx of novice users to Linux. I don’t think we need a bunch “Linux ate my files” incidents if it can be avoided by a simple change, which itself can be easily reversed if you didn’t like it.

 reply
11
edited

Yes this is absolutely how Linux operates, but it’s embarrassing and primitive, and it’s actually decidedly a bug.
I haven’t done much programming for many years, but you used to be able to see if you went a step deeper into the file system operations, whether the file you are copying still has parts in cache.
Just because nobody does it, doesn’t mean it’s not a bug.

There is no sense in showing a progress bar that is wrong anyway.

 reply
3

It’s not a bug, just a difference in prioritization. It makes more sense for a server and less for a desktop with removable devices

 reply
6
edited

How is it not a bug? The info shown is decidedly wrong!
Would it also not be a bug if your weather app shows freezing 8 C° tomorrow when it’s going to be 40 C°?
Because there’s a perfectly understandable explanation, that they only count to 32 because temperatures didn’t get higher than that 30 years ago, so it counts down from zero when it’s above 40, because that’s how we’ve done it for years.

Just because you know why, and it’s a little bit cumbersome to do it correctly doesn’t mean it’s not a bug.
It’s not only a bug, it’s a lazy ass bug.

 reply
2

If it’s lazy then the fix should be easy, right? Send a PR

 reply
4

You’re reading it wrong and misinterpreting the message. It’s like me saying that your Celsius thermometer is wrong because water freezes at zero instead of 32. Just because you know why doesn’t make one or the other wrong, it’s just different.

That being said I think I would also prefer it the other way.

 reply
1

Being able to use a GUI for creating mounts is something people have asked for.

I know I can use smb4k to mount, maybe it could he extended to write a mount point at boot.

I know for me it’s trivial to simply write a systemd mount rule, but it seems other people want to do it with a GUI.

 reply
21
edited

Its done already and will be out in coming update

 reply
8

Do they still do 15 minute bugs? That could still use some work.

Occasionally I get an itch to try Plasma and immediately get disappointed every time as I encounter some sort of bug just setting up the panel. Last time I tried was 6.6.5, so it wasn’t just a point 0 software issue.

As a side note, I still get so confused by the “new” panel/desktop edit mode introduced in 6.1.

 reply
9

Yeah the panel editing could use some work. Lots of weird size and space issues still too. I rather like how Cosmic is developing their panel. Still customizable but so much easier to understand. With the great changes recently to application themes the panel sort of seems the least polished part now.

 reply
4

Stability and bug fixes.

 reply
8

bugfixes and qol

 reply
7

Add more panel types and weird customsation. Im really looking forward to the union update where theming gets easier. Hate svg but can manage CSS.

 reply
5

There’s a preview version of union in Plasma 6.7 I believe, although it’s a bit bare-bones IIRC.

 reply
1
edited

A replacement for what we had with khotkey that allows to intercept and replace key codes, both globally and for specific applications. Bonus points if it also has global mouse gestures.

Issues here and here.

 reply
5
edited

There was a fantastic blog post about accessibility problems with Wayland, but I think Wayland is upstream of KDE, isn’t it?

In other words, do you know if what you’re suggesting within scope, or is it upstream? Or maybe it’s both, and KDE and Wayland both need changes to enable proper accessibility?

I don’t know enough, but I’ll see if I can track down that blog post and post about accessibility. Worst case, it lets KDE devs know that accessibility with KDE/Wayland is a major issue for many users.

Edit: I found the post: My Accessibility Stack and the future on Wayland

 reply
1
edited

If there’s still wayland protocol extensions required for this functionality (which I don’t think, kwin should have everything it needs, protocols would only be necessary if you’d want a DE-agnostic client application to manage the hotkeys), then KDE is in the best position to get things moving. With wayland development, nothing gets done without a reference implementation and vote from a big compositor, so sitting back and waiting “until things improve” is rarely a valid strategy.

I don’t know about the accessibility side of this, but from how uninterested the devs are every time it’s brought up I can only assume that a keyboard-centric workflow is no longer a focus for KDE. Which is a shame, because with khotkey, KDE previously did provide the best experience out of all major DEs. Now it’s down among worst, when even Gnome(!) has retained some kind of custom hotkey functionality on wayland.

 reply
2

It’s tightly interconnected with accessibility because alternative input systems, like eye gaze input, macros to expand text, and other accessibility tools for alternative input hardware all friends in the same types of window-agnostic input interacting. (Similarly for output hardware, I think?)

Like, custom text replacement with XCompose breaks because of how Wayland “silos” programs, which is why ~/.XCompose files only partially work in KDE Plasma. If Wayland/KDE fully implemented accessibility tools, then it would be possible to solve all of these problems.

Or, at least, that’s my layman’s understanding of the situation.

 reply
1

Plasma bigscreen or maybe something gaming console like screen for tv with focus on controller based input/navigation

 reply
5

This surely has more to do with upstream Qt, but I wish they can give way to people make things for KDE with Rust/Zig/C3/Whathaveyounow. Like, you know, besides the C++/QML combo (and the PyQt bindings thing).

That and overlooked apps like Falkon that have so much potential but could get some more love.

 reply
4

If they made a 1:1 easy to deploy Gnome-like template, I’d switch in an instant.

 reply
3

I think I would try give KDE a chance again if this template existed, but just knowing that I can go and customize it would fuck me up.

Ironic that the only Gnome extension I use is a KDE Connect port…

 reply
2

Good remote desktop support.

(Aka make KRDP actually work)

 reply
3
edited

(Aka make KRDP actually work)

You mean KRDC & KRFB? I’ve used them almost exclusively for my Remote Desktop needs, mostly without issues.

Any VNC software should work with KRDC.

 reply
1
edited

Screen sharing in video conferencing software (bbb, webex, meetme etc). It just doesn’t work consistently. Sometimes (rarely) it just works as expected. Sometimes everybody sees a “black screen with a mouse pointer”. Sometimes your screenshare is tiny and squeezed into a quarter of the virtual screen. Sometimes it’s enlarged instead and doesn’t fit into the virtual screen. Sometimes the popup (Wayland recording bridge???) doesn’t show up. It’s russian roulette basically, this shit definitely needs more eyeballs.

 reply
1

Unattended remote desktop has been the major sticking point for my switch, I have gotten it to work once I have logged in, but someone needs to log me in after a system reboot. I heard they were working on this with the new login manager, but I haven’t heard anything more about it.

 reply
1

Go back to 3.5, that was the best!

 reply
-4

Use TDE then!. I really like it.

 reply
6

Anyone passionate about KDE and has a vision to share is welcome to submit a proposal.

i’m out.

 reply
-15

Comments in Linux@programming.dev

Not breaking things.

 reply
10

Plugin docs and libs for Rust.

For the next 20 years, please a rewrite in rust. The build chain is an absolute horror.

 reply
1
Insert image