[BRLTTY] BrlAPI and touch.c

[Mario Lang]

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

> Mario Lang, le Sun 24 Feb 2008 09:43:30 +0100, a écrit :
>> Can we somehow epxport ATC info via BrlAPI?
>> Maybe by adding a special read_key alike function which returns
>> an array of bytes?
>
> Just to give a short answer right now: yes, sure!
>
> Now, we need to think about the details, since there are a lot of other
> kinds of information that we would like to provide, such as the size of
> the currently driven device, etc.

ATC information seems to be pretty specific.  It can be
exposed as a byte-array with length of the display, where
all values indicate the pressure values on the individual cells.
Its really much like brlapi_write, but in the reverse direction.

It isnt immediately obvious to me how to merge this information
with anything else.  It looks like a single function
call (brlapi__readTouch()?) would be what we need in this case.
We will probably want to queue up touch changes
at brltty side, so that a client does not miss information
between two calls.
But then, we would have to pull for two individual input
packets on the client side, effectively forcing the use of non-blocking
since a keypress delivered during readTouch is
waiting could not reach the client.

In dynamic bindings like Python, we could solve this
by making the readKey function more highlevel and actually
return a class instance.  So we could do things like:

text = "Hello World!"
brlapi.writeText(text)
input = brlapi.readKey()
if isinstance(input, brlapi.TouchInformation):
    if all([char==' ' or pressure>0 for char, pressure in zip(text,input)]):
        text = "done"
        brlapi.writeText(text)
elif isinstance(input, brlapi.KeyPress):
    bindings[input.command](input.argument)

And command, argument, flags and so on could be
class properties which call expandKeyCode on demand, caching
the decoded values in instance variables.
TouchInformation would just be an list-like object, with
__len__ and __getitem__ methods and an interable interface.
Alternatively, it could make sense to also send
the text that was displayed when the pressure change arrived
back down to the client, so that the client does not need to keep track
of every change to the display.  This would eliminate the
need for the "text" variable in the above pseudo-example.

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