PieFedKDE Plasma 6.4 Tackles An 18 Year Old Feature Request, More Wayland Protocols Added
cm0002www.phoronix.com/news/KDE-Plasma-6.4-Starts-May…
8 Comments
Comments from other communities
I wonder if they'll ever fix this 24 year old bug...
https://bugs.kde.org/show_bug.cgi?id=36065
(Note they closed it but it doesn't sound like they actually did fix it.)
I just tried this and it seems mostly fixed? Focus changes on button down but the window is raised on button up
A_norny_mousseI would not want to call this a bug. It's a limitation at worst.
And even after reading to the end I have no idea if it's dictated by kwin itself or by the underlying server.
It has accumulated slightly different complaints from different users to the point that the discussion became muddied.
One dev pointed out that the underlying gui server disallows this behavior, but during the discussion it has become increasingly unclear what "this behavior" even is, or what the "supposedly easy" fix would be.
My thoughts/experience:
- my window manager (under Xorg) can be configured to react differently on mouse-up or mouse-down. Whether one clicks on the client window or titlebar doesn't matter, it goes to the wm first.
- the supposedly unsolveable problem practically never happens to me because I like to arrange my windows side-by-side, on different workspaces etc. but never on top of each other.
- lastly, dragging and dropping between application windows used to be so hit and miss on Linux that I stopped doing it at all, or at least not expecting it to succeed. No idea if it got better in the past decade. This might have something to do with the fact that I'm not using a full-blown DE.
Question to you: is the desired behavior possible to achieve with some other WM? Can you disprove the claim made by one or two of the devs, that it just isn't possible to solve within kwin/KDE because the underlying graphical server is responsible for this limitation?
So, Windows has fully optimal behaviour here:
If you click on an area of the window that cannot be dragged from, it raises it on mouse-down.
If you click on an area of the window that can be dragged on, it *doesn't* raise if you start a drag, otherwise it raises it on mouse-up.
That's the desired behaviour. I agree people didn't really explain that clearly.
I haven't looked into it for over 20 years but as I recall it is impossible to do this with X11. I have no idea if Wayland added some kind of support for this, but I would be quite surprised given how long it took them to do screenshots.
Part of the difficulty is that you need to somehow query an app on mouse-down if it *might* start a drag. I have no idea how Windows does that... but... they solved it decades ago.
Clearly not a bug. “Should” is a clear feature request.
I am not saying they should not do it. Maybe they have. But closing the “bug” was the right thing to do.
Bugs and feature requests need to be prioritized and processed quite differently.
I hope it's configurable, I like the dialog. Though I guess it'd be faster just to remember to hold shift (?) for copy instead
Good point, thanks!
Genuinely don't understand how this wasn't a thing already. Huge KDE fan but...
when kde and linux were way more niche than they are now kde decided to do it that way for the reason bro666 mentioned, and nobody got around to changing it till now, because the people who contributed to kde weren't bothered by it, for the most part.
Because seem people prefer to have choice right of the bat? Giving people control over their decisions, even small ones like this, is the KDE way.
Huge KDE fan too but there are a couple defaults that make me scratch my head. Like single clicking opens stuff instead of just selecting
Double clicking to open is the default now.