Re: [orca-list] On binding (or not binding) speech and magnification functions

I am a primary braille user but not primarily an orca user as I just find ways to work at the console if I can. That may be because of braille issues in orca since I don't tend to pursue things if they don't work and I have another way of handling them. That being said where are the biggest issues with braille in orca that people are seeing. What can I do to help with this since as I say I am primarily a braille user.


On Sun, 25 Apr 2010, Joanmarie Diggs wrote:

Hey all.

I had a wacky idea regarding what we might consider doing with respect
to binding speech and magnification functions -- should we decide it's
worth doing.

Disclaimer: This is an idea which came to me around 3 AM, and I'm just
brainstorming with y'all. The following might one day be the
officially-recognized dumbest idea ever had. <grin> With that

Seems to me that there are three important and somewhat parallel
features that might be binding-worthy.

1. Enable/Disable {speech, magnification}
2. Increase/Decrease {speech rate, magnification level}
3. Cycle {speech punctuation type, magnification zoom window type}

We could add a setting -- a really obvious and easy to find setting --
whereby the user can indicate if the primary output/mode is speech or

Then we'd have a total of four new keybindings:
1. Toggle the enabled state of the primary output/mode
2. Increase the level of the primary output/mode
3. Decrease the level of the primary output/mode
4. Cycle the cycle-able feature of the primary output/mode

The corresponding bindings could be:
1. Orca + e: Enable/disable
2. Orca + Up: Increase the level
3. Orca + Down: Decrease the level
4. Orca + <something>: Cycle the cycle-able feature

Notes (and more ideas):

1. Apologies to folks whose primary output/mode is braille. I'm not
discounting your needs. (In fact, I'd really like to see Orca's braille
support improved and increased so that it could truly be the *only*
output a user accesses and that user would have everything he/she
needed.) But right now, with the current braille support, I'm not seeing
the parallel need for toggle/increase/decrease/cycle in braille. If I'm
wrong, let me know.

2. I initially thought that Orca + c might be a good cycle keybinding,
but that would conflict with an existing OpenOffice command. Then I
thought we could do Orca + Left for previous type and Orca + Right for
next type, but that conflicts with two Firefox bindings. We can't use
the letters on the right side of the keyboard, because those conflict
with the flat review commands for laptop users. Oy! Which brings me to:

3. We could always have a primary output/mode modifier, similar to the
Orca modifier. It could default to, say, the Super key but would be
configurable. If we do that, then we could do:

1. Super + e: Enable/disable
2. Super + Up: Increase the level
3. Super + Down: Decrease the level
4. Super + Right: Next presentation mode
5. Super + Left: Previous presentation mode

Or combine the next/previous into Super + c. The reason I think it's
worth having a previous and a next is due to magnification. For one
thing, there's six modes of magnification (and I think there will be a
lens mode in the gnome-shell magnifier, so that will be seven modes). If
you accidentally went one past the mode you want, it's kindof a drag to
have to do a full cycle to get back to the one you want.

4. As a reminder, I'm not saying we should do this necessarily. It's
merely a response to those of you who indicated there might be some
value in binding modality-specific features, <joking> as long as they
were for the modality you happened to use </joking>.


orca-list mailing list
orca-list gnome org
Visit for more information on Orca.
The manual is at
The FAQ is at
Netiquette Guidelines are at
Log bugs and feature requests at
Find out how to help at

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]