Bug 482191 - Middle clicking on a window no longer closes it
Summary: Middle clicking on a window no longer closes it
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-present-windows (other bugs)
Version First Reported In: 6.0.0
Platform: NixOS Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: qt6, regression
Depends on:
Blocks:
 
Reported: 2024-03-01 20:10 UTC by Naxdy
Modified: 2024-03-04 23:25 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 6.0.1
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Naxdy 2024-03-01 20:10:48 UTC
SUMMARY
While in the present windows effect, middle clicking it with a mouse wheel no longer closes it. (it still works in the overview effect however)


STEPS TO REPRODUCE
1. Trigger present windows effect
2. Middle click on any window

EXPECTED RESULT
Window closes

OBSERVED RESULT
pure and utter sadness (window does not close)


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: NixOS
(available in About System)
KDE Plasma Version: 6.0.0
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2

ADDITIONAL INFORMATION
-
Comment 1 Nate Graham 2024-03-01 21:40:07 UTC
Can confirm.
Comment 2 Nate Graham 2024-03-01 22:17:41 UTC
In general we're rethinking destructive defaults like middle-click-to-close, but until and unless we have a config option for this so that people who want it can opt into it, I think we have to keep it by default.
Comment 3 Naxdy 2024-03-02 09:56:01 UTC
I mean, middle-click-to-close is a pretty universal standard that works literally everywhere. Browser tabs, dolphin tabs, konsole tabs, yakuake tabs, etc. I don't see any reason why it shouldn't be the default, personally.

But even if you wanted to move away from it in desktop effects for whatever reason, I'd at least expect the behavior to be consistent across the board. As I said, currently it's implemented in the overview effect, but not in present windows, which just feels extremely odd.
Comment 4 Nate Graham 2024-03-04 19:56:19 UTC
Well, not *literally* everywhere. :) Not all tab bars do implement it, and also the Present Windows effect isn't a tab bar.

I agree that being inconsistent is a problem in and of itself, though. Hence why I've elected to keep this bug report open.
Comment 5 Bug Janitor Service 2024-03-04 21:23:27 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5356
Comment 6 Nate Graham 2024-03-04 23:14:58 UTC
Git commit d0a6bd34041b4c156cf23764f66b85b39c1ce3c2 by Nate Graham, on behalf of Dominique Hummel.
Committed on 04/03/2024 at 23:14.
Pushed by ngraham into branch 'master'.

effects/windowview: use correct enum value for `PointerDevice`

M  +1    -1    src/plugins/windowview/qml/main.qml

https://invent.kde.org/plasma/kwin/-/commit/d0a6bd34041b4c156cf23764f66b85b39c1ce3c2
Comment 7 Nate Graham 2024-03-04 23:25:21 UTC
Git commit 63a39646ea088aec71f3e4269bb00dbe7acebad7 by Nate Graham, on behalf of Dominique Hummel.
Committed on 04/03/2024 at 23:15.
Pushed by ngraham into branch 'Plasma/6.0'.

effects/windowview: use correct enum value for `PointerDevice`


(cherry picked from commit d0a6bd34041b4c156cf23764f66b85b39c1ce3c2)

b842efc0 effects/windowview: use correct enum value for `PointerDevice`

M  +1    -1    src/plugins/windowview/qml/main.qml

https://invent.kde.org/plasma/kwin/-/commit/63a39646ea088aec71f3e4269bb00dbe7acebad7