this post was submitted on 04 May 2025
39 points (100.0% liked)

Linux

7221 readers
290 users here now

A community for everything relating to the GNU/Linux operating system

Also check out:

Original icon base courtesy of [email protected] and The GIMP

founded 2 years ago
MODERATORS
Ategon
anzo
dwraf_of_ignorance
39
KDE Plasma 6.4 Tackles An 18 Year Old Feature Request, More Wayland Protocols Added (www.phoronix.com)
submitted 2 days ago by [email protected] to c/linux
9 comments fedilink hide all child comments
top 9 comments
sorted by: hot top controversial new old
[–] FizzyOrange 6 points 2 days ago (3 children)

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.)

[–] LeFantome 2 points 1 day 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.

[–] [email protected] 2 points 2 days ago* (last edited 2 days ago) (1 children)

I 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?

[–] FizzyOrange 3 points 1 day ago (1 children)

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.

[–] [email protected] 1 points 20 hours ago* (last edited 20 hours ago)

I feared the answer would be "it works on Windows"...

[–] [email protected] 1 points 1 day ago (1 children)

I just tried this and it seems mostly fixed? Focus changes on button down but the window is raised on button up

[–] FizzyOrange 2 points 1 day ago (1 children)

That's definitely better, but still not as good as Windows. If you click on an area that isn't a drag source it should be raised on button down. I presume it doesn't do that?

[–] [email protected] 2 points 2 days ago

Random Captain Haddock insults.py

😁