SUMMARY As originally reported in bug #438148, on wayland, the window operations menu "Desktops" section has checkboxes for desktop entries instead of just a "radio button" style toggle, and it behaves that way, allowing a window to be located on multiple (but not all) desktops. The problem with this feature is that the common workflow we are used to for virtual desktops, where we can just move a window to another desktop using the window operations menu, becomes needlessly complicated - instead of opening the menu and selecting "Desktops" -> target desktop, now we have to first toggle the checkbox for the destination desktop, then uncheck the checkbox for the current desktop. This becomes even more confusing and time consuming because the window operations menu closes after each click (see bug #438197), but even without that issue, it still makes the simple and expected use case surprisingly complicated in favor of a new, advanced and rather niche feature. STEPS TO REPRODUCE 1. Open the window operations menu for a window you want to move to another desktop. 2. Open the "Desktops" sub menu. 3. Select the destination desktop. OBSERVED RESULT A checkbox gets ticked (and the menu probably closes) and the window stays in the current desktop. EXPECTED RESULT The window should be removed from the current desktop and mapped to the destination desktop. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.22.80 KDE Frameworks Version: 5.83.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION As suggested in bug #438148, another option that might make it easier for users that want to keep the old simple behavior of: select -> moved, while still allowing the more complex use case of selecting multiple destination desktops for the window - and assuming that bug #438197 gets fixed as otherwise it will just be confusing - is to have different behavior for clicking the checkbox (or selecting the entry with the keyboard and hitting Space) vs clicking the name of the desktop entry (or selecting with the keyboard and hitting Enter), so that only the first behavior will "use the checkboxes" and the second behavior will do the old style switching by automatically unchecking any currently selected checkboxes - similar to how selecting "All Desktops" currently works.
Yeah, this is ridiculously confusing IMO. I think it should be radio buttons and one desktop or all desktops, not n desktops.
(In reply to Nate Graham from comment #1) > Yeah, this is ridiculously confusing IMO. I think it should be radio buttons > and one desktop or all desktops, not n desktops. Personally I also think that the multi-virtual-desktop-per-window feature isn't worth the UX hurdles (though I appreciate that this feature is useful and would love to still see it in some form, possibly as a kwin window rule), but as you can see in https://bugs.kde.org/show_bug.cgi?id=438148#c1, kwin developer Vlad Zahorodnii implied that the kwin dev team is committed to this feature and it is here to stay. Especially as bug #438197 is closed as "upstream", there should be a facility to let users keep the "move window to another virtual desktop" workflow at the same complexity level as the X11 implementation as I believe it cannot be argued that the new feature is even close to being as relevant in day-to-day activities as "move window". Another option that I can think of is have the menu distinguish between left click and right click and when RMB is detected, switch from radio buttons to checkboxes and allow the user to fiddle with them (from reviewing Qt documentation there aren't obvious ways to do this, but there are a few less obvious ways for this effect to be achieved).
The current version of kwin on wayland (neon unstable) now has two sets of entries in the "Desktops" windows operation sub-menu: checkboxes for applying the window to multiple desktops and a new set of entries that are labeled "move window to <desktop>". This is indeed a solution to this bug, and I'm OK with that, though I wouldn't say the result look is particularly nice.
Can you still reproduce this bug with a more recent version?
(In reply to postix from comment #4) > Can you still reproduce this bug with a more recent version? As I mentioned in comment #3, the new (as of 2021) double set of desktop entries does solve the problem and I use it all the time. As also mentioned, it isn't a very nice looking solution and more specifically: as I always use "move to" and never use the check boxes, and I access the menu with the keyboard - and the number key shortcuts are reserved for the check boxes - the extra hassle of using more "down arrow" keys to get past the first set of entries is really annoying. I had hoped that in the mean time someone will figure out a better approach, or I would love to see a user study of which mechanism users preferred, but I believe if people are even using the window operations menu to move deskopts these days (and not just dragging things in the overview or desktop grid effects), they use mostly the "move to" operations and I would have loved to see those at the top of the list and bound to the number key shortcuts. Also - I still think think the checkbox mode is - in and by itself - unusable due to issue #438197.
(In reply to Oded Arbel from comment #5) > [...] if people are even using the window operations menu to move > deskopts these days (and not just dragging things in the overview or desktop > grid effects), they use mostly the "move to" operations So, it just occurred to me that the (again, probably useful) feature of having the window on multiple desktops, would probably not play well with window dragging in the Overview and Desktop Grid effect - so I tested it and indeed, you can't do a "copy to other desktop" operation in these and if you drag a window that was in multiple desktops, it will collapse all the copies and you will get just the one copy you moved. At this point I would suggest just dropping the "on multiple desktops" feature or hiding it behind a disabled-by-default configuration, as it doesn't play well with other very prominent and nice looking features of kwin.
The original UX issue is resolved now, so this bug is effectively fixed.