Bug 438148 - Window operations menu desktop selection menu uses "checkbox behavior", sometimes
Summary: Window operations menu desktop selection menu uses "checkbox behavior", somet...
Status: RESOLVED NOT A BUG
Alias: None
Product: kwin
Classification: Plasma
Component: platform-wayland-nested (show other bugs)
Version: git master
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-06 08:38 UTC by Oded Arbel
Modified: 2021-06-07 10:13 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Oded Arbel 2021-06-06 08:38:09 UTC
SUMMARY
Under wayland the "Desktops" sub menu of the window operations menu behaves very differently from the way it works under X11. It uses a "checkbox" UI instead of a "radio button" UI and also tries to behave that way but the result is inconsistent, confusing and annoying:

1. When a window is on one desktop, selecting another desktop's entry from the window operations desktops sub menu copies the window to the other desktop. This may be desired functionality but it is unexpected for people coming from X11 and virtually any other graphical computer desktop that implements virtual desktops.
2. When a window is on "all desktops", selecting a non current desktop's entry looks to be actually moving the window - it is removed from the current desktop.
3. When selecting an entry from the "Desktops" sub menu, the window operation menu closes - which is like the behavior under X11, but the checkbox paradigm makes this confusing because they way expect to use checkbox is to check and uncheck until we get the configuration that we need before dismissing the UI.
4. The common use case of moving a window to another desktop becomes twice as cumbersom - instead of: opening the menu, navigating, selecting; now you have to: open the menu, navigate,select the destination, open the menu again, navigate, select the origin to "uncheck" it.

SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.22.80
KDE Frameworks Version: 5.83.0
Qt Version: 5.15.3

ADDITIONAL INFORMATION

While I do think that having the "allow window on multiple desktops but not all of them" is useful, I think the current implementation leaves much to be desired and should not be left as is - it's UX makes it worse than not having that capability at all. This feature must either be reverted back to how it works in X11 (which is not perfect but definitely a lot less confusing and cumbersome), or changed significantly - and I have a few suggestions:

1. By default allow for "1 click" move: if the user clicks on the entry, not on the checkbox itself, or uses the keyboard to navigate and hits Enter - move the window instead of copying it.
2. Allow manipulating the checkboxes without closing the menu: if the user clicks on a checkbox, or select an entry with the keyboard and presses Space, just toggle the checkbox and don't close the menu. This might lead to an awkward behavior where the window is no longer mapped to the current desktop but its window operations menu *is*, and there is also no UI for "applying" (clicking outside the window seems unsatisfactory, as well as using the ESC key), but I think both issues can be solved by not applying checkbox-style manipulation until the user triggers a new entry in the menu labeled "apply" or some such. Maybe the new entry can only appear if the "checkbox manipulation" has happened, or it may be just disabled.
Comment 1 Vlad Zahorodnii 2021-06-07 07:27:47 UTC
> 3. When selecting an entry from the "Desktops" sub menu, the window operation menu closes - which is like the behavior under X11, but the checkbox paradigm makes this confusing because they way expect to use checkbox is to check and uncheck until we get the configuration that we need before dismissing the UI.

This seems like a regression.

---

Points 1 and 2 are intentional. Point 4 needs some thinking.
Comment 2 Vlad Zahorodnii 2021-06-07 07:30:29 UTC
Tracking multiple issues in a single bug report is hard. Can you please file bug reports for 3 and 4?

Closing the bug report as we usually don't track multiple issues in a single bug report.
Comment 3 Oded Arbel 2021-06-07 10:13:55 UTC
(In reply to Vlad Zahorodnii from comment #2)
> Tracking multiple issues in a single bug report is hard. Can you please file
> bug reports for 3 and 4?

Opened bug reports #438197 and #438198.