[BRLTTY] Default for key tables - OFF or ON

Mario Lang mlang at delysid.org
Tue Feb 3 03:31:38 EST 2009


Samuel Thibault <samuel.thibault at ens-lyon.org> writes:

> Dave Mielke, le Mon 02 Feb 2009 18:41:30 -0500, a écrit :
>> >The default keymap should of course be as less intrusive as possible.
>> 
>> Should we use one of the three we have now or should we crate a basic key table 
>> which, for example, uses CapsLock
>
> Mmm, IIRC speakup uses CapsLock by default, doesn't it?

Yes, and Orca uses KPInsert.  I am not sure we can solve all compatibility
issues here.  The GUI case can probably be solved by temporarily
setting key sniffing into passthru mode while on a tty claimed by a client.
This would give full keyboard control back to BrlAPI clients.
However, I am not sure we can solve all compatibility issues with
other key sniffers.  CapsLock is *the* key to use if you want to
steal a modifier, because its so conveniently located and generally
unused in reall apps, and because most screen readers use it already (for
laptop layout at least).  In the current implementation, we even manage
to have its original toggle functionality still available.
BTW, when does speakup steal its keys?  Before potential input clients
that grab a device, or when a key finally reaches the kernel without being
grabbed by an user space app?  i.e., does speakup or brltty win over
a double-bound key combination?

Anyway, I think if a user choose to configure braille and speech
via two different screen readers, we can hoepfully except they made themselves
familiar with the help info for their particular devices.

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/>
  .''`. | Get my public key via finger mlang/key at db.debian.org
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-      <URL:http://delysid.org/>  <URL:http://www.staff.tugraz.at/mlang/>


More information about the BRLTTY mailing list