Re: [orca-list] revisiting the issue of unbound keybindings

[Michael Whapples <mwhapples aim com>]

Hello,
I think Nolan makes some good points. There are a range of different 
users, all using different combinations of the various presentations, so 
why should one group be favoured over another. Although I don't use 
magnification, I can see how those who use magnification are being left 
out a bit (as well as a lack of default key bindings being bound, they 
also don't get asked if they want magnification in the initial set up 
questions).

Now the solution as I see it would be to have key profiles/groups which 
can be enabled and disabled (possibly as various presentations are 
turned on and off). Either these would be enabled depending on the 
choices of presentations in the initial set up questions or there would 
be extra questions added for this.

Some of the groups would be: Base (very basic key strokes, open 
preferences, enable/disable different presentations, etc), speech (keys 
specific to speech, eg. increase/decrease rate, pitch, voice, change 
echo mode, etc), Braille (Braille specific keys), magnification 
(magnification specific keys, increase/decrease magnification, 
enable/disable cross hairs, etc), enhanced structural navigation (I have 
called it enhanced, I don't really know where the boundary should lie, 
should all structural navigation keys be in this, is heading core enough 
to have in another, etc), additional features (those which people should 
be present but questionably lie outside orca's scope, eg. battery 
status, time, etc). Other groups/profiles may exist.

Now the question comes up, what happens if a user customises keybindings 
and then enables another profile which makes use of the key? I would say 
a warning dialog box should be shown to indicate the clash and offer the 
user the chance to redefine either keybinding, maintain existing 
keybinding (ignoring the one in the profile being enabled) or overwrite 
the current keymapping. I would say the default option in such a dialog 
should be maintain the existing mapping ignoring the new one.

OK, that's my thoughts on this, what do others think of this idea?

Michael Whapples
On 01/-10/-28163 08:59 PM, Nolan Darilek wrote:
> Ah, you made my point before I could. :)
>
> In essence, it struck me as interesting that adding shortcuts for 
> speech was advocated while adding more for magnification wasn't 
> because the latter wasn't used, when in fact there's no guarantee that 
> the former was universal either. :) It'd be great to come up with some 
> sort of guideline on whether or not a default keybinding is added. To 
> that end, here's what seems to have surfaced in this thread as a 
> series of starting points:
>
> * Not binding a default key, while trying to be minimalistic, may make 
> discovering some functionality more difficult. I might add that it may 
> also make discussing how to use such functionality more difficult. For 
> instance, if someone were to wonder how to move to the next heading on 
> a page, it's much easier to say "Press h" than it is to say "Enter 
> Orca preferences using insert-ctrl-space, navigate to the keybindings 
> tab, bind the function to a key of your choice then use that key."
>
> * Keys shouldn't be bound or not based on whether or not certain 
> functionality is universal or not. Whether they are or aren't should 
> also be consistent across presentations. That is, either create 
> default keybindings for speech, magnification and braille commands or 
> don't do so, but don't create default bindings for speech and neglect 
> other methods.
>
> * Don't create keybindings that step beyond Orca's scope, or that 
> shell out to external commands. I already have keybindings set for 
> volume functions, for instance. Making Orca responsible for media 
> controls would seem to me to be way outside its scope. Sure, media 
> keys can be tough to find on some keyboards, but so might pgup/dn, 
> home, end, etc. and not knowing where those are can make computer use 
> just as difficult in its own way.
>
> An easy solution to all of these would seem to be creating default 
> keybindings for just about everything, then letting the user 
> disable/change any they don't need. It makes Orca's wealth of 
> functionality discoverable and communicable. It doesn't favor any one 
> presentation style over another. But if the desire is to remain 
> minimal, then a bit more thought needs to be put into which bits of 
> functionality are highly useful and which aren't, and care must be 
> taken to equally favor all presentation methods.