r/kde
Linus, I fixed Middle Mouse Scrolling for you
We all know Linus' biggest pet peeve is the lack of system wide middle click autoscrolling. I built a universal solution called midscroll that operates at the kernel input level, meaning it perfectly replicates the Windows autoscroll behavior across every single application on both Wayland and X11. It anchors your cursor, uses the exact same speed curve you are used to, and runs entirely in the background.
FOSS under the Unlicense.
You can check out how it works here: https://github.com/gnhen/midscroll
EDIT: Now with a Settings menu GUI. Supports Hold & Drag as well as Toggle mode. Native scrolling mode supported.
The KDE Command Feature is insanely poweful
For context, I typically stream my games from my pc to my steam deck over sunshine (and tailscale because uni wifi really doesnt like to talk to each other-), but ive always had a couple issues. Mainly controlling my wire guard configurations, the monitors power state (because I still need the monitor on to get the virtual monitor to start up), and other bs that comes with using 3 different pieces of software at once, all tied together by scripts. So I figured out how to control all of these things by terminal commands (and aliases in the case of WireGuard), and now have a page on my phone that allows me to trigger every event over my tailnet in case I'm not physically with the computer.
Panel configuration
I'm attempting to use the "Panel Colorizer" widget to get those tiny bubble like panels on the same side with clean outlines, but I'm having difficulty layering more than 1 panel on the same side. It also shows an editable icon at all times which I don't like. What are ricers using for Plasma 6 panel configuration? I use Cairo dock for my bottom dock which contains my icon only task manager. Just trying to complete the slim top panel containing system tray and time.
Image of unwanted icon in the middle
Built Plasma 6.6.6, KDE Frameworks 6.24.0, KDE Gear 25.12.3, QT 6.10.2
With the announcement of the Plasma LTS for 6.6 on Kubunutu I thought I would have a play around with getting it packaged for Debian 13. There were a couple of caveats in that I had to build against QT 6.10 for 6.6.6 which also meant rebuilding some other packages that depend on QT Base. Also needed backports for newer wayland protocols, mesa and pipewire. Been an interesting little project. This is just in a VM so far and I'm deploying the debs with a local apt repo.
May see if I can get a little CI/CD pipeline going for myself when the TechPaladin team start publishing their LTS branches.
| Component | Debian 13 | Upgraded To |
|---|---|---|
| KDE Plasma | 6.3.6 | 6.6.6 |
| KDE Frameworks | 6.13.0 | 6.24.0 |
| KDE Gear | 24.12.0 | 25.12.3 |
| QT 6 Stack | 6.8.2 | 6.10.2 |
| Mesa / Vulkan | 25.0.7 | 26.1.2 (backports) |
| Wayland Protocols | 1.38 | 1.44 (backports) |
| Pipewire | 1.4.2 | 1.4.9 (backports) |
just some appreciation for everyone contributing
i've been using KDE tools since before i even knew what KDE was. krita was my first full-featured drawing program/image editor (back when i was drawing on a mediocre windows vista PC with a mouse), then i found an old version of KDE on windows through some youtube videos (never ran it myself, but many of my openshell skins were around it) and i developed more of an interest in it.
plasma was one of the more familiar-looking and accessible DEs when i made the jump to linux full-time. (especially as someone who's legally blind, being able to set up everything usably with maybe 5 clicks total was a godsend - i've noticed some accessibility gaps, but i usually need to have someone else read off my computer to me while setting up a screen reader and large font/screen zoom, while plasma was easy to navigate for me OOTB. i think it took me longer to set up firefox than plasma, LOL.)
KDE connect is genuinely so easy to use and is a lifesaver as someone who runs several devices with different OSes, especially with running some apple products in a primarily non-apple ecosystem. i don't want to even THINK about how much of a pain it was to get my ipad to communicate with my PC before finding KDE connect, and while some features aren't fully implemented on my ipad, the file transfer functionality alone is a lifesaver. i got it running on an old macbook as well, and yet again, the integration makes my life so much easier.
and kdenlive is frankly a great editor for my uses. it took me a bit to get used to, as i'm coming from much more basic tools (legitimately just my phone's built-in editor), but it's fun to play around with and the few hang-ups i've had were solved with a google search.
even things like kmag and kspeech have been invaluable - there's just some things that large font and a screen reader can't quite fill in for (such as images without alt text), and i'm also selectively mute IRL. while i use them less frequently than other KDE apps, i don't know how i got by without them (i sometimes have kspeech routed to voice/video calls, as an example, when my friends are using VC but i'm not able to speak directly and we're in a game with no private text chat).
i'm the furthest thing from a "brand loyalist." i use whatever device or tool happens to be available, needed, or convenient, and it's rare for me to find one integrated ecosystem that fully fits my needs. KDE has done that, so kudos to the KDE team and everyone who's contributed! i hope one day i'm able to offer more contribution than just an appreciation post, it still blows my mind how well things work together.
and if any of the KDE team sees this and are looking for visual accessibility feedback, i'm more than happy to help! i haven't encountered any major hang-ups thus far and quite appreciate how much is already built-in, and i'd love to see that trend continue :) i simply don't have enough direct coding skill to contribute much there.
tl;dr: thank you KDE team and anyone who's contributed to KDE projects. it's really amazing what y'all have done.
Dragging windows between virtual desktops directly from their thumbnails in plasma overview
Is there a way in Plasma Overview to allow dragging a window from one virtual desktop's thumbnail to another?
For example, suppose I am currently on Virtual Desktop 1 and press Meta+W to open Overview.
I can see:
- the windows on Virtual Desktop 1 at full size, and
- miniature previews of Virtual Desktop 2, 3, etc., including the windows currently open on those desktops.
What I'd like to be able to do is:
- Open Overview while remaining on Virtual Desktop 1.
- Grab a window from the miniature preview of Virtual Desktop 2.
- Drag that window onto the Virtual Desktop 1 area.
- Release it.
The window is moved from Virtual Desktop 2 → Virtual Desktop 1.
In other words, the miniature virtual-desktop previews should act as interactive drop targets for their windows, not merely as previews/navigation targets.
Currently, if I want to accomplish this, I have to:
- Open Overview.
- Switch to Virtual Desktop 2.
- Drag the window to Virtual Desktop 1.
- Return to Virtual Desktop 1.
This is considerably more cumbersome than simply manipulating the window where I can already see it. The current approach requires 3 more actions than would be required if the windows could be moved directly between the previews (or previews to opened workspace).
I'm aware that Desktop Grid provides a way to move windows between virtual desktops, and that Overview already supports moving windows between desktops in some contexts. I'm specifically asking for this capability from the miniature desktop previews in the Overview effect.
This would make Overview much more useful as a global virtual-desktop/window management interface, rather than primarily a window switcher for the current desktop.
Also, I took help of AI in wording it out, since it was very difficult to explain the context otherwise.
Lunar Plasma: a Lua scripting interface for KDE Plasma!
Hello everyone! I'm building something I've been wanting to make for a while: a scripting layer that abstracts KDE Plasma's desktop functions, so you can automate small parts of your desktop without having to dig through D-Bus interfaces every time.
You can check out the project on GitHub: https://github.com/Vaithre/lunar-plasma
Plasma already lets you do a lot, but whenever I wanted to automate something I usually ended up combining shell commands, qdbus, small scripts, etc etc. It works, but every script has to deal with the same details again. I wanted a small layer that handles that part, so the script can focus on what it is actually trying to do. For example, changing the volume should be as simple as plasma.sound.set(50).
I concluded it needed to be easy to embed, making it agnostic to whichever scripting language you choose. That's how Lua ended up being chosen to drive this project!
It is still in an early stage of development, but enough functionality has already been implemented to make sharing it worthwhile. Please feel free to try it out, share your thoughts, or even contribute. Lunar Plasma is still at a stage where changing the underlying structure is relatively easy. Thanks!
I changed my mind about KDE Plasma. Once I got a minimal install going with a modular build, I warmed up to the de after all :) I have myself an older PC gaming device now!
Fedora KDE Plasma ricing
so i want to have some tipps for advanced Fedora KDE Plasma ricing (customization) because i have already tried waywallen, sddm-astronaut-theme, etc. and i already tried other distros like ubuntu, arch, cachyos, omarchy, bazzite, ... so i just wanted to ask for advanced tipps for ricing and i am NOT afraid of the Console. AND i dislike anime girls.
Dolphin checksum calculations very slow?
So I have a large .ISO file and wanted to confirm the checksum via Dolphin with <right click on file> -> properties -> checksums tab -> enter known checksum.
On a 30GB iso this ground away on the processor for around 2 minutes on a high spec desktop PC with no result so I exited and instead of entering a checksum I just tried hitting 'calculate' on the SHA256 checksum. Waited well over a minute and again felt like this is too long.
In contrast, running sha256sum <filename> in the terminal returned the correct result in around 10-11 seconds.
If anyone can confirm / deny this disparity on a very large file, please let me know your distro and what you saw. I'm on aerynOs which I doubt anyone else is running but wanted to know if this is a general KDE issue or a distro specific one before reporting appropriately.
Cheers
EDIT - I've raised a bug report.
Fedora 44 KDE audio level problem
Hello,
Since monday I am having this problem where the volume bar "resets" to 5% every time I change it. And when I use my keyboard's volume buttons, it mutes the output.
Does anyone have any idea of what I could do to troubleshoot?
How to do it
​
Hii im planning to switch from windows to linux mint once i get my own laptop. I'm trying to find a way to make my design work, what i had in mind was per workspace it had it own apps in in like lets say in ws 1 i had YouTube etc and on another workspace i have different apps and no apps from ws 1 is that possible and i might use kde plasma for this. I also wanted it to look like those character selection screen like in the image if possible any guides?
Issue using Logitech G502 additional Keys
A few weeks ago i went for using cachyos as my main os. Its quiet painful for a lot of reasson (which are mostly fixable i think). One of the Most annoying things is me having trouble using my mouse. So i got the Wireless G502 from Logitech. First i tried using Piper because i heared alot of good things about it but for some reasson it wouldnt regonize my mouse even after install ratbag oder what ever it was called. So swapped to using solar which is fine but i couldnt use my additional mouse buttons on top of the Mouse (Picture G7 and G8) for muting in discord (which i configured in the logitech ghub). Thats why i installed Input Mapper, in this app i made a preset which binds the mouse buttons to f15 and f16, which i setup up as my hotkeys in discord. But everytime boot into cachyos these Settings arent working not even after i apllied them again. What can i do to fix this?
This was the closest I could get to my old Frutiger Aero, does anyone have a thema Aero recommendation? It doesn't have to look like Windows, just Glass or Blured.
Closing application from taskbar (preview)
Can I bind the middle mouse button so that clicking the taskbar hover preview closes the window, instead of having to right-click it and select 'Close'? I've yet to find the answer on any forum or discussion. Hope anyone knows how to do this!
Force Opacity on Normal Windows breaks Desktop layer (permanent black, survives plasmashell restart) — Plasma 6.7.4, Iris Xe, Wayland
I'm using Fedora Linux 44 with KDE Plasma 6.7.4 on Wayland (Kernel 7.1.8, Qt 6.11.1) on a Dell Inspiron 15 5510 (Intel Core i5-11320H, Iris Xe).
Important background (a bug I discovered): Forcing opacity (Force opacity) via Window Rules on any Normal Window causes a solid black layer to appear instead of transparency on the desktop layer (plasmashell Desktop layer, layer-shell FirstLayer) — even after adding an explicit exclusion rule for plasmashell with higher priority ordering and a "Do not affect" value. Worse: this state is not fixed by restarting plasmashell (kquitapp6 plasmashell && kstart plasmashell), but requires removing the force-opacity rule and doing a full system reboot. This matches a documented category of bugs in KDE Bugzilla (
#366318 and
#449445) related to a stuck compositing state for plasmashell that only clears with a full reinitialization of kwin_wayland. I previously tried KWIN_DRM_NO_AMS=1, but it later turned out to be unrelated (it was a misleading coincidence with disabling the rules at the time of testing).
My goal: Create a genuine "frosted glass" effect (transparency + blur) on regular windows, while avoiding this bug entirely this time. I need:
1.An alternative method (not Window Rules force opacity) for achieving the glass effect — such as KWin's built-in Blur effect directly, or the external Force Blur effect — while avoiding any interaction with the desktop layer.
2.Confirmation of whether the built-in Blur effect in Desktop Effects (as opposed to Window Rules) structurally avoids this bug, since it doesn't force a new compositing state onto the Desktop window type.
3.Any precautions or correct settings ordering that prevents this bug from recurring on Iris Xe hardware.
Widget Group Widget
I've published the Panel Widget Group Widget (Plasmoid) on GitHub. It's a super simple widget that lets you group any multiple widgets into a detailed view and place them as one item on your panel.
You can add multiple widgets using the "Add" button and choose which one to use for the compact view (the item shows up on the panel). That's literally it.
A game mode to turn off effects?
I'm new to KDE customisation. Got a pretty decent look going that I'm happy with. Even got wallpaper engine working. However I'm afraid there's too much going on and while idling my Rtx 4060 goes upto 40% usage.
I don't mind it (unless it damages my system)
However I was wondering if there's a command or a widget to enable "game mode" that turns off screen rounding and transparency. Something I can just turn on before playing a game
Using kde on cachy
Make Simon Stålenhag Picture of the Day provider a little bir safer
So I was messing around with KDE's lock screen wallpaper providers and noticed there’s a Simon Stålenhag Picture of the Day provider.
Cool feature. Then I had the stupid but reasonable thought:
> this thing is downloading random images from the internet and displaying them on my lock screen. What happens if the server gives KDE something malicious?
So I started digging.
First checked where the provider comes from.
On Arch:
pacman -Ql kdeplasma-addons | grep -i simon
Output:
/usr/lib/qt6/plugins/potd/plasma_potd_simonstalenhagprovider.so
So it comes from kdeplasma-addons, through Plasma's Picture of the Day system.
Then I checked the source.
The Simon provider roughly does:
download metadata
→ get image URL
→ KIO downloads the data
→ QImage::fromData(data)
→ KDE gets a decoded image
→ image gets cached
The relevant line is basically:
QImage::fromData(data)
I looked for anything that could execute the downloaded file.
Nothing.
No:
QProcess
system()
exec()
chmod +x
dlopen()
The network response is treated as image data and passed into Qt's image decoder.
So giving it an ELF binary called wallpaper.jpg doesn't get you anywhere. Qt tries to decode the bytes as an image and the decode fails.
Then I checked what KDE was actually leaving on my machine.
POTD cache is here:
~/.cache/plasma_engine_potd/
My Simon file:
-rw-r--r-- 216721 bytes simonstalenhag
No executable bit.
file reports:
JPEG image data, JFIF standard 1.01,
96x96 DPI, baseline, precision 8,
2556x1390, components 3
The other POTD providers looked normal too:
wcpotd → JPEG
simonstalenhag → JPEG
flickr → JPEG
apod → JPEG
bing → JPEG
I also ran:
find ~/.cache/plasma_engine_potd -maxdepth 1 -type f -perm /111
Nothing.
The cache implementation is actually nicer than I expected.
KDE doesn't seem to keep the original network response around as the wallpaper cache. The provider produces a QImage, then the common POTD cache code saves that decoded image as JPEG.
So it ends up going through something like:
network response
→ Qt image decoder
→ pixel data
→ new JPEG
→ cache
That also kills the obvious polyglot idea.
If somebody sends a valid JPEG with random executable data appended to the end, KDE decodes the picture and writes a fresh JPEG from the decoded image. The extra junk shouldn't survive that process.
At this point I was pretty satisfied with the downloaded-file side of it.
Then I found something considerably dumber.
The Simon provider gets its metadata from this third-party GitHub repository:
a-andreyev/simonstalenhag-se-metadata
That request uses HTTPS.
The actual Stålenhag images listed in the metadata, however, use URLs like:
http://simonstalenhag.se/tftlbig/2.jpg
Plain HTTP.
In 2026.
The provider reads the URL from the metadata and passes it to KIO. I couldn't find any HTTPS requirement or hostname allowlist in the Simon provider.
So you have:
KDE
↓
third-party metadata repository
↓
image URL
↓
HTTP download
↓
Qt image decoder
That gives someone capable of modifying the HTTP response a chance to feed arbitrary image data into Qt's decoder.
They'd still need an actual vulnerability in Qt or one of the image decoding libraries to turn that into code execution, so this is nowhere near "random Wi-Fi guy sends shell script, KDE runs shell script."
Still, feeding attacker-controlled bytes into an image parser over unauthenticated HTTP is a completely avoidable attack surface.
The metadata repo also adds another dependency.
If that GitHub repository were compromised, the image URL could theoretically be changed to an attacker-controlled server.
The response would still have to survive QImage::fromData(), but the attacker would get control over the input being sent into the image decoder.
I also had a look at the lock screen itself.
kscreenlocker uses a NoAccessNetworkAccessManagerFactory which blocks non-local network requests coming from the lock screen's QML engine.
Nice.
POTD uses KIO though, rather than the regular QML network manager, so I'm not confident enough from static inspection alone to claim that every possible POTD network path is blocked while the greeter is running.
There are also some signs in the code/comments that KDE intended POTD data to be prepared/cache-fed for the lock screen, but that part of the architecture looks like it has changed over time.
My installed versions:
kdeplasma-addons 6.7.4-1
kscreenlocker 6.7.4-1
qt6-base 6.11.1-1
kio 6.28.0-1
So after going through all this, I don't see a realistic path where a fake .png or .jpg simply turns into an executed binary.
The part worth caring about is the parser boundary.
Remote bytes reach QImage::fromData(). If the decoder has a memory corruption bug, a specially crafted image could potentially hit it before KDE ever gets to the safe re-encoding/cache stage.
I'd change a few things in the Simon provider:
- force HTTPS
- restrict the hostname
- don't accept arbitrary image URLs from the metadata source
- restrict expected image formats if possible
- cap response/image sizes
The feature looks pretty reasonable overall on an updated system.
The plain HTTP image delivery is the one part that made me raise an eyebrow. There's really no good reason for that to still be there.