https://bugs.kde.org/show_bug.cgi?id=438148
Bug ID: 438148
Summary: Window operations menu desktop selection menu uses
"checkbox behavior", sometimes
Product: kwin
Version: git master
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: platform-wayland
Assignee: kwin-bugs-n...@kde.org
Reporter: o...@geek.co.il
Target Milestone: ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
