[BRLTTY] Xbrlapi

[Willie Walker]

Hi Samuel:

This definitely helps with the "why", but I also need help with the
"how".  :-)  

Orca currently only has bindings for CMD_FWINLT, CMD_FWINRT, CMD_LNUP,
CMD_LNDN, CMD_TOP_LEFT, CMD_BOT_LEFT, and CMD_HOME, and it also listens
for any cursor routing key.  We do want, however, to allow people to
create bindings for other commands if they wish.  The result is that we
will have several discontiguous ranges of keys to listen for.

Given this, what is the best way for Orca to tell BrlAPI/BrlTTY what
Orca is interested in?  A small code snippet would really help solidify
this for me.  :-)

Will

On Mon, 2006-12-11 at 21:33 +0100, Sébastien Hinderer wrote:
> Samuel Thibault :
> > Willie Walker, le Mon 11 Dec 2006 15:08:23 -0500, a écrit :
> > > > It looks like this is what happens. Orca should ignore the key events
> > > > that it doesn't handle.
> > > 
> > > I believe Orca does indeed ignore them.
> > 
> > By "ignore", I mean "call brlapi_ignoreKeyRange", not only "do nothing
> > when the keypress event comes".
> 
> Yes, it is very important that Orca calls brlapi_ignoreKeyRange for
> every key range it is not interesded in. The way things work in BrlAPI's
> server is as follows:
> when a key is pressed on the braille device's keyboard, the server checks
> whether the application that currently has the focus ignores or accepts
> the key. If the key is in the set of accepted keys, it is sent to the
> application, which can do whatever it wants, including nothing at all,
> synthetising a keyboard event, use it for navigation, etc.
> If, o& the contrary, the pressed key belongs to she set of keys that are
> _ignored_ by the application, then the key is returned to brltty, which
> handles it as if no application would have the focus on this terminal.
> 
> Here is an example that should illustrate the interest of such a
> mechanism.
> 
> Consider a braille device having both an alphanumeric keyboard and
> navigation keys. Suppose this device is connected to a computer working
> in text-mode, running brltty and with one application connected to
> BrlAPI's server. If the application would have to handle every key coming
> from the braille device (which was how BrlAPI worked at the very
> beginning), then the application would certainly want to insert the
> alphanumeric keys at the console, just like if they would have been typed
> at the PC keybord. But inserting a key at the console is something brltty
> already does, so why should appliction have to re-invent the wheel, we
> wondered. And that's how the possibility for clients to ignore keys was
> introduced. In our case, the client application would most probably
> accept the navigation keys and ignore the alphanumeric keys, which would
> hence be sent to brltty, which in turn would insert them to the console.
> 
> Hope this helps,
> Sébastien.
> _______________________________________________
> This message was sent via the BRLTTY mailing list.
> To post a message, send an e-mail to: BRLTTY at mielke.cc
> For general information, go to: http://mielke.cc/mailman/listinfo/brltty