Summary: | On Wayland, during Drag'n'Drop, if the cursor hovers over a non-target window, it quickly receives focus and rises above the others | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Yevhen Popok <xalt7x.service> |
Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | agurenko, dougshaw77, nate |
Priority: | NOR | Keywords: | qt6, usability, wayland |
Version: | 5.92.0 | Flags: | xalt7x.service:
Wayland+
|
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=440534 | ||
Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/a47d6ffe9b2703c01784212ca47bee927bad5a73 | Version Fixed In: | 6.0 |
Attachments: | Demo of the window raising issue during drag-n-drop on Wayland |
Description
Yevhen Popok
2024-01-29 23:49:11 UTC
Can confirm on Neon Testing, Plasma 5.92.90, Frameworks 5.249.0, Qt 6.6.1 > Firefox window doesn't "steal" focus when cursor hovers over it
This is the intentional behavior. If the drag pointer hovers over a window, the user likely wants to drop there.
The task manager behavior is strange though and perhaps it needs a follow up.
On X11, the drag and drop operation behaves differently because kwin is not in charge of input, x11 clients typically grab input in such cases. (In reply to Vlad Zahorodnii from comment #2) > > Firefox window doesn't "steal" focus when cursor hovers over it > > This is the intentional behavior. If the drag pointer hovers over a window, > the user likely wants to drop there. I can't agree with that. Most current KDE Plasma users are not robots/machines to perform Drag'n'Drop action with determined speed and accuracy. Especially, we can't expect that from older people, non-experienced users or users with disabilities. I can think of at least 3 cases where the current focus behavior is harmful to usability: 1. Drag'n'Drop file from file manager window to some other application to transfer file (web browser, chat app etc) 2. Drag'n'Drop browser tab to attach it to another browser window 3. Drag'n'Drop item from file manager to the terminal (to quickly get file/folder path) In a perfect world, I would like to avoid "drag-n-drop focus changes" for both maximized and floated windows (like Windows does - https://www.reddit.com/r/kde/comments/fz6as1/a_feature_that_i_really_missed_from_windows_is_it/). This would allow KWin users to perform simple Drag'n'Drop operations without much hassle (e.g. enable/disable "Always on Top"/"Keep above others", tile windows, drag file to the panel, activate Task Switcher etc.) Re-opening since there's in fact an open and approved merge request that fixes this, so apparently it's not as intentional was was originally believed. :) https://invent.kde.org/plasma/kwin/-/merge_requests/5076 > so apparently it's not as intentional was was originally believed
It is. If you hold the cursor over a window, it will be raised. That's intentional.
Sure, but for how long? Raising it almost immediately after the cursor stops moving--which is what this bug report is about--is not intentional, as evidenced by the fact that you approved a merge request to change that. :) The EXPECTED RESULT talks about no raising window, i.e. matching the behavior on X11 as demonstrated in the linked video. As I understood it, that was about removing/adding option rather than tweaking the timeout. Since the current behavior on Wayland is intentional, I closed the bug report with RESOLVED INTENTIONAL. (In reply to Vlad Zahorodnii from comment #8) > The EXPECTED RESULT talks about no raising window, i.e. matching the > behavior on X11 as demonstrated in the linked video. As I understood it, > that was about removing/adding option rather than tweaking the timeout. > Since the current behavior on Wayland is intentional, I closed the bug > report with RESOLVED INTENTIONAL. Yes, you're right, the expected result is to match X11 behavior as it provides arguably better usability. As a regular user, I may not be familiar with the codebase (e.g., timer values), what's in charge of input, how X11 clients grab the focus and other technical details of the KWin/X11/Wayland internals. All I know exactly is that Drag-n-Drop in the above-mentioned cases work better on KWin X11 and Mutter Wayland than on KWin Wayland. Surely, increase of the timeout is the welcome change that hopefully will make this issue less noticeable for the majority of users. Git commit 8d44ece8743dcc32445edd718740905fad5ab661 by Vlad Zahorodnii, on behalf of Xaver Hugl. Committed on 31/01/2024 at 08:41. Pushed by vladz into branch 'master'. input: increase raise timeout for drag and drop to 1s This should be long enough to not happen accidentally, but short enough to not be annoying and discoverable. M +1 -1 src/input.cpp https://invent.kde.org/plasma/kwin/-/commit/8d44ece8743dcc32445edd718740905fad5ab661 Git commit a47d6ffe9b2703c01784212ca47bee927bad5a73 by Vlad Zahorodnii, on behalf of Xaver Hugl. Committed on 31/01/2024 at 08:42. Pushed by vladz into branch 'Plasma/6.0'. input: increase raise timeout for drag and drop to 1s This should be long enough to not happen accidentally, but short enough to not be annoying and discoverable. (cherry picked from commit 8d44ece8743dcc32445edd718740905fad5ab661) M +1 -1 src/input.cpp https://invent.kde.org/plasma/kwin/-/commit/a47d6ffe9b2703c01784212ca47bee927bad5a73 |