GNOME Bugzilla – Bug 536825
Allow bypass of Orca's keyboard commands
Last modified: 2009-03-10 00:05:18 UTC
Users want to be able to bypass Orca's interception of keyboard events. From the Orca mailing list, the proposed behavior is similar to Windows screen readers: "You activate byPass function pressing orca+delete, then bypass mode is activated only for 1 keystroke, after, byPass mode toggles off".
the bypass keystroke must be reassignable to another keystrokes
Created attachment 112806 [details] [review] revision 1 Will please review. Thanks! Also with or without my patch, default.py pylints to a 10 with the exception of: W0333:5172:Script._detectCycle: Use of the `` operator W0333:5182:Script._printObjInfo: Use of the `` operator Are those things we wish to add an ignore for or things we want to change?
(In reply to comment #2) > Also with or without my patch, default.py pylints to a 10 with the exception > of: > W0333:5172:Script._detectCycle: Use of the `` operator > W0333:5182:Script._printObjInfo: Use of the `` operator > > Are those things we wish to add an ignore for or things we want to change? Ha! They've been there for a long time, as long as you use a newer version of pylint. It's a newer warning, I believe, and adding it to the pylintrc file would cause pylint to fail if used with an older pylint. Since I've been just plain happy that people are actually pylint'ing, I didn't want to force an upgrade and have just been checking the default.py pylint results by hand. If we've all made the upgrade to a newer pylint, or are willing to upgrade, then I'm all for adding W0333 to pylintrc. This, however, has nothing to do with this bug. ;-)
> If we've all made the upgrade to a newer pylint, or are willing to upgrade, > then I'm all for adding W0333 to pylintrc. I can go either way. I'm perfectly capable of checking by hand as well. As long as you know it really pylints to a 10.0 even though it technically doesn't, I'm good. ;-) > This, however, has nothing to do with this bug. ;-) Agreed. :-) So.... Whatcha think about the solution? Is it: a) [testing required] b) [will] (I need more time in the day to do reviews), or c) [joanie] (Back to the drawing board with you!) :-)
> Agreed. :-) So.... Whatcha think about the solution? Is it: > > a) [testing required] > b) [will] (I need more time in the day to do reviews), or > c) [joanie] (Back to the drawing board with you!) It's (d) [will] (my inbox keeps filling up with e-mail for some strange reason) ;-)
(In reply to comment #2) > Created an attachment (id=112806) [edit] > revision 1 > > Will please review. Thanks! This patch looks fine to me (thanks), though I'm now wondering if Delete is the best keysym to use. The reason being is that Orca+KP_Delete is used as the find command. So...maybe we should use "BackSpace" instead? PS - I checked in a new pylintrc. No need to fill our inboxes with stuff regarding that any more. ;-)
Created attachment 112920 [details] [review] revision 2: use Orca+BackSpace > This patch looks fine to me (thanks), though I'm now wondering if Delete is the > best keysym to use. The reason being is that Orca+KP_Delete is used as the > find command. So...maybe we should use "BackSpace" instead? Done. Thanks for the review!
I can't think of a better key to use. I'm OK with backspace. I withdraw my objection.
Okie dokie. Patch committed to trunk. Moving to pending.
Could we please change the message when this key is pressed to: "enter key to pass through" Otherwise this bug is good to close.
I certainly could do that. The wording was hard. My only question about the new wording is that "Enter key to pass through" sounds like a prompt in a dialog with a control in which one could actually enter a key. All we're doing is merely ignoring whatever the next command happens to be. If I'm the only one who feels that way, I'll update the string when I get back from the errand I'm about to run.
I'm happy to replace enter with press.
The wording is definitely tough. The one in the patch now seems to make the most sense to me. The alternative suggestions still sound like they are asking the user to do something instead of telling them the current state, and I find them kind of confusing. How about something like one of the following: Entering temporary bypass mode. The next keystroke will be ignored.
The thing I didn't like about mode was that it implies that you might have to toggle it off again. That said I don't want to waste our time over the wording so do whatever you like.
I still don't like the message but that's fine.