https://bugs.kde.org/show_bug.cgi?id=430440
--- Comment #15 from Oded Arbel <o...@geek.co.il> --- (In reply to Gauthier from comment #14) > > The lack of keyboard shortcut to > > "move a window to activity X" > > > as been pointed out in Bug 411688 IMO, the ability of the user to assign a custom keyboard shortcut to a "move to activity" operation does not solve the inaccessibility of the taskbar to keyboard operation. Please don't conflate "being able to assign keyboard shortcuts" with "being able to use the keyboard to select and activate things". My point is that I understand that some people can make a good use the taskbar with a mouse, but as someone who prefers to use the keyboard - the taskbar is completely inaccessible to me and I use it as visual reference only. As such, adding capabilities to the taskbar is *not* a good replacement to missing window operations menu functionality (the window operations menu is *very* keyboard accessible). (In reply to Gauthier from comment #13) > 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)? Tying "apply operations" to mouse movement is a problematic proposition - some pointing devices (and some people) are very inaccurate and having a wrong move trigger an operation that takes significant effort to revert (its not just CTRL+Z), will be very frustrating to the user. ESC would work, but you do want additionally something that is both discoverable and can be operated by a mouse. I thought about this a bit and in the context of a menu we are precluded from a lot of guided interaction we can do with dialogs: you can't have explanatory text and you can't have an "apply" button. There are some use cases that are hard to do "properly" in a menu - so can we just stop pretending to care about them? I want to support the following use cases: 1. Show the window in all activities. 2. Add the window to this one additional activity. 3. Move the window to this one other activity. I don't want to support the following use cases as I think they are niche, can be achieved with a combination of actions (1), (2) and (3) (albeit slower, as the menu would need to be reopened), and not worth sacrificing the usability of (1), (2) and (3) for: 4. Add the window to 2 or more additional activities. 5. Move the window to 2 or more other activities. (all the above also applies to virtual desktops, as appropriate, as it is basically the same thing on a different axis). What do you think? Do you often find yourself moving a window from the current activity to 2 other activities (as described in comment #2)? -- You are receiving this mail because: You are watching all bug changes.
