https://bugs.kde.org/show_bug.cgi?id=430440
--- Comment #16 from Gauthier <g.gue...@posteo.net> --- (In reply to Oded Arbel from comment #15) > (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". Yes you are right, I meant that at least it provides a way for those who use the keyboard to move an activity :) > 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). I fully agree that it is not a replacement but the person who worked on this, also tried to address the kwin/title bar menu, they just didn't know how to do it. What I meant is that the process has started trying to solve the issue with "Show in activities" menu(s) as a whole. But yes the kwin / title bar is still not solved needs addressing. > (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. While I fully agree with you in principle, and I think you're making very good points regarding accessibility. However in that case I'm not sure it applies since currently the mouse action (a click on a tick box) triggers the apply operation straight away as the menu closes and the change is applied. What I propose is actually a "delay" of the apply operation, until a further mouse action is done, i.e. moving the cursor outside the menu area. What do you think? > 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)? I would very much agree that we should prioritise the use cases 1. 2. and 3. I would think that even 1. and 3. would be the ultimate priority. Unless you still think it is a problem, it does feel like my above proposition (apply changes on moving mouse outside the menu / press ESC key) would solve most use cases you've outlined, no? -- You are receiving this mail because: You are watching all bug changes.
