Bug 438148

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.