GNOME Bugzilla – Bug 102656
Request for 'sticky' Alt-Tab popup
Last modified: 2006-09-13 01:07:25 UTC
A comment to me from Earl Johnson, one of Sun's accessibility guys: "[Ctrl+]Alt+Tab is doable but difficult for someone with a physical disability. What do you think about having the following also work: [Ctrl+]Alt+Tab to post the popup, [Shift+]Tab to cycle between the icons in the popup, Spacebar to select the window hilited by the icon. It's inconsistent with how Windows and GNOME currently operate, but not in the functions Tab and Spacebar perform. Perhaps a sticky posting of the popup is already a customizable feature?" I told him there was probably more chance of having this implemented if it could 'just work' invisibly alongside the current behaviour, but unfortunately I can't quite see how it could... any bright ideas?
Could probably do something like that, sure. I probably wouldn't do it as an option that changes what the switch_windows binding does, I'd probably add another possible binding called show_window_switcher or I don't know. Something like that. Reasonably tricky to implement well, but should only take a few hours.
Could it be done using the wnk-applet window-list and a free floating panel?
If the user can do Alt-tab at all (to start the popup) then they can do it repeatedly. I assume the difficulty here is that the user may be able to do Alt-tab, but not easily hold alt by pressing tab multiple times? In this case, just press Alt-tab (and release afterward) more than once. If Alt-tab is hard (and I can certainly see that it might be) this can be configured to something easier, such as something useless like Pause. Or am I misunderstanding the issue here?
It is indeed possible to bind Alt+Tab to single keys (say F11 and F12 for example) if you want to do that. I don't know if that meets the accessibility need or not.
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
Binding Alt-Tab to something else is a pretty acceptable workaround I think, which is why I've only tagged it as an AP4... it does go a little against our "make everything as accessible as possible without having to change any preferences" ideal, but I'm not sure it would be possible to meet that here anyway.
I think there are some misunderstandings here. If AccessX StickyKeys is enabled, then Alt-Tab is two keystrokes. Alt-Alt-Tab currently (if StickyKeys is enabled) does what Earl is asking for, if I understand correctly. Earl? I am not sure bindings Alt-Tab to a single key is something we'd want to do by default.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
So, what's the proposed solution here? Are we suggesting that the [Ctrl-]Alt-Tab popup should behave in a "sticky" fashion if StickyKeys is turned on? I.e. the interaction method becomes: [Ctrl, then] Alt, then Tab (popup appears), then arrowkeys or [Shift, then] Tab, then Space (to select) or Esc (to dismiss). And that it continues to behave as it does now if stickykeys is turned off?
calum: that's one possibility. To respond to Rob, note that repeated presses of 'Alt-TAB' do _not_ cycle through the window list. This is a 'featured' behavior which Havoc has indicated we doesn't want to change. The only way to cycle through the focussed windows at the moment is to hold Alt down while pressing TAB multiple times. For a sticky-keys user, then, Alt(press)-TAB-TAB-(Alt release) becomes Alt-Alt-TAB-TAB-Alt-Alt, i.e. six keypresses are required instead of three. That's not nice for users who have troubles using the keyboard in the first place. I don't know if Calum's suggestion (metacity keybindings behave slightly differently if StickyKeys is on) is acceptable or not, hp will have to weigh in there. However I would note that StickyKeys already changes the behavior of the keybindings from the user's perspective, so perhaps the 'inconsistency' is appropriate.
For comparison: on Windows XP the key sequence with StickyKeys to get switch to the third application: Alt, Alt, Tab, Tab, Alt. The first two Alts locks it. The first Tab goes to the 2nd app, the second Tab to the 3rd app, and then the final Alt key dismisses the dialog and switches to that app. Mirroring this in GNOME would eliminate one key (5 instead of 6), and mean the StickyKeys user has two additional keypresses as compared to the mainstream user. That two key addition is a fixed cost -> one additional key to start, and another to stop, no matter how many apps we're switching past. Note: this is the same number of keys as in Calum's trial proposal (above). The only way to reduce it further than this is to have a two key combination that brings up the dialog in a sticky fasion (e.g. Meta, Tab to do the equivalent of Alt, Alt, Tab). I think we should just copy Windows in this case.
The Windows approach sounds fine to me, I'd suggest that metacity use XKB to detect sticky keys being enabled and if enabled, automatically switch to this behavior. Don't know how hard it is to implement. If adding a patch do PATCH keyword and move back to next metacity release milestone.
a11y team, sounds like the ball is in our court to provide a patch for this ASAP if we want it for GNOME 2.6.
looking at the bug again, and re-reading/checking what Windoze does. I think our current sticky-keys behavior is on par with Windows, i.e. same number of keystrokes. So I think this is an RFE but not a blocker by any means. I have lowered the 'AP' priority accordingly. Any objections?
I am looking into the metacity code and have a couple of questions. When I run metacity as follows to turn on debug: METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 METACITY_DEBUG_BUTTON_GRABS=1 metacity I notice that metacity doesn't seem to report the event of the META key itself being pressed. Since the proposed solution for the bug-report indicates that the window-switch pop-up needs to be displayed when the META key is hit twice in a row, I obviously need to know when the key is pressed. Why doesn't the meta_display_process_key_event function in keybindings.c seem to notice report the META KeyPress/KeyRelease events? Is there something tricky I need to do get this KeyPress event? Also, do you have any suggestions regarding how I could best handle the recognizing of the TAB key as being META-TAB. One idea would be to modify all keypresses that are received after locking (after hitting the META key twice), so that all keypresses have the modifier so that TAB would become META-TAB. Does this make sense, or is there a better way that you would recommend?
Brian, did you get my email? Not sure we need to urgently work on this one. The meta-key pressed twice solution is _already_ what metacity does when sticky keys is on (and latch-to-lock is on). So this feature is already available. The RFE is for something simpler, which is lower priority IMO. Just misunderstandings in the bug discussion I think.
See also bug 109798.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
*** Bug 109798 has been marked as a duplicate of this bug. ***
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
I just tried this out, and behavior is identical to korn@sun.com's description of Windows behavior. In other words, only one alt is needed to release at the end. So, can I mark this as fixed?
I think you can Elijah.
Sweet. :)