https://bugs.kde.org/show_bug.cgi?id=430440
--- Comment #13 from Gauthier <g.gue...@posteo.net> --- (In reply to Oded Arbel from comment #11) > (In reply to Gauthier from comment #7) > > Should it get marked as resolved? > > Looking at the MR that was merged, it adds the workaround to the task bar > context menu. This issue is about the window operations menu, so the MR does > not solve this issue in that it doesn't fix the window operations menu. You are right that technically this bug is about the menu in the title bar so it is not addressed by this new commit. Though the problematic behaviour is the same in both the title bar (kwin) menu and the task manager menu so it is an attempt to start address the issue as a whole. However, I agree with you that the proposed approach in the commit may not be the best (see below in response to your comment). > I'm not sure what is the use case for the task bar right click menu as I > almost > never use it and there is no keyboard shortcut to get to it. IMHO the window > operations menu should be the target for any improved behavior its better > accessible by both keyboard and mouse (Fitz law). I agree with ederad, it is a common use case, it is nice not to have to bring the window into focus to move them. I use that a lot. The lack of keyboard shortcut to "move to an activity" as been pointed out in Bug 411688 > > (In reply to Gauthier from comment #8) > > @Oded Have there been any progress on your MR for VDs, and if so, does it > > seem likely to also work for activities? > > I did not move forward with my work on the checkboxed window operations > submenus (I'm treating desktops and activities the same for this). I didn't > have a lot of time for that, but more than that I'm very confused about the > situation - in Kwin Wayland there is a workaround for the desktops menu that > is very similar in behavior to > https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/231, but not > identical, and of course that it wasn't implemented for activities. > > I think before any additional work is done, there should be some effort to > understand what is the UX that we are aiming for and how it should apply to > all relevant use cases - wayland, x11, window operations menu, plasma shell > task bar menus, activities, desktops, whatever else is relevant. Currently > there are too many different behaviors for things that should basically be > the same. I'm not sure how/where/when/with who to start such a discussion. I agree with you tat this whole things needs tidying up and made consistent across X11/Wayland, Activities, VDs, kwin menu and task manager menu. Not sure where to start either. > On that note, I personally dislike the "dual control" UX that is offered in > Wayland windows operation menu and the above mentioned MR: on my systems I > have few activities (2 or 3 normally) and many virtual desktops (6 or 8) and > while the "checkbox + move to items" is kind of manageable in the activities > selection, it is almost unusable for virtual desktops (the wayland window > operations desktops menu takes more than half the height of my screen now) - > it actually takes noticeable time and thought to locate the menu option I > need in order to just move this one window to desktop 4. I believe we can do > better, and would like to have a discussion about that. I think you are right here. When I looked at the commit I thought it would only work well if one has only 2/3 activities, but with many, the double of menu items would get long and cumbersome. Would it be possible to only keep the tick boxes, but ensure that the menu stays open AND changes are only applied after either: the mouse moves out of the menu (if using the mouse), or the ESC key is pressed (if navigating using the keyboard)? -- You are receiving this mail because: You are watching all bug changes.
