[BRLTTY] More then one connection to brlapi

[Samuel Thibault]

Hi,

Willie Walker, le Mon 13 Feb 2006 07:58:31 -0500, a écrit :
> >Jan Buchal, le Sun 12 Feb 2006 17:39:35 +0100, a écrit :
> >i.e. the tty number seems to be passed somehow as python argument. You
> >can probably set the correct tty somehow there. But it should  
> >rather do
> >just like gnopernicus:
> >
> >- if WINDOWSPATH is defined, then just call brlapi_getTtyPath(NULL,  
> >0, BRLCOMMANDS)  (this will be the preferred way in the future)
> >- else, get the XFree86_VT property of the root window, and call
> >brlapi_getTty(vt, BRLCOMMANDS);
> 
> This sounds reasonable.  I'd like to learn more about these.
> Do you have a pointer to the docs on brlapi_getTtyPath?

man brlapi_getTtyPath should be fine. For more general documentation,
see the brlapi manual brltty/Documents/BrlAPI-HTML/BrlAPI.html,
BrlAPI-3.html in particular.

(also available on the web:
http://www.mielke.cc/brltty/doc/Manual-BrlAPI/English/BrlAPI.html )

> >Btw, since brlapi is LGPL for some time already, orca could just use
> >brltty/api.h API definitions rather that relying on the (possibly
> >changing) ABI.
> 
> There are a couple of design goals with Orca: we'd like to be
> able to build it and run it without requiring brltty to on
> the machine (hence Orca's runtime resolution of brltty symbols),

configure should be used for such issue. Yes, when reinstalling brltty
afterwards, you have to recompile orca. That's how things have worked
for ages.

Now, if you want to provided binaries that don't depend on brltty but
are able to use it if available, you could just do like gnopernicus:
implement your own separate module that depends on brltty, and
dynamically load _that_ one, with your own ABI.

In general, dlopen() shouldn't ever be used, since it bypasses sonames,
it hence means asking for bugs :)

> and we want to be able to drive brltty from Python (hence
> duplication of brltty constants in Python).

Well, we are working on a python binding...

> Ideally, any ABI changes would be backwards compatible.

Of course, and that's what we try to do. For instance, BRLCOMMANDS is
now NULL, so that it happens to work in such example. But since BrlAPI
is still a bit experimental, we sometimes have to do some ABI shifts.

Regards,
Samuel