Orca BrlTTY transition from v3.7.2 to v3.8 (was Re: How to make brltty read Chinese uner gnome-terminal?)



Samuel, thanks for bringing me into this discussion!  I'm not on the
blinux-list redhat com, so the conversation snippet below is the only
context I have.  I'm CC'ing the orca-list gnome org list since that's
where the majority of Orca discussion should happen.

The main issue we're dealing with here is a substantial change to BrlAPI
from BrlTTY v3.7.2 (BrlAPI 0.4.1) to BrlTTY v3.8 (BrlAPI 0.5).  It's
generally for the better, since BrlAPI 0.5 now includes Python bindings
(THANKS!!!!), but it's also not smooth because binary incompatibilities
were introduced.  

In Orca, we're trying to make sure we are flexible enough to support
both versions during this transition period in BrlTTY, and we also don't
want to require people to recompile/reinstall Orca when they move from
one version of BrlTTY to the next.  In general, I think we're pretty
close (the GNOME CVS HEAD code works great for me and many others).  One
thing that slipped through the cracks, however, was the check in
configure.in.  It's really only a warning message -- Orca *should*
automatically find and use the right version of BrlAPI at run time,
assuming BrlTTY/BrlAPI are appropriately installed.

Here are the details:

The BrlAPI check in Orca's configure.in currently looks like the
following:

AC_CHECK_LIB(brlapi, brlapi_initializeConnection,,
[brlapi_available="no"; AC_MSG_WARN(Could not find libbrlapi.so - you
need BrlTTY >= 3.7.2 and BrlAPI >= 0.4.1 installed to use braille)])

All it's doing is attempting to verify that libbrlapi.so has the
brlapi_initializeConnection symbol in it.  If libbrlapi.so cannot be
found, or the symbol doesn't exist, then the configure assumes BrlAPI is
not available and issues a warning message.

In looking at the latest BrlAPI code, it looks like
brlapi_initializeConnection was demoted from a method to a macro.  This
incompatible change seems to be the source of the failures since the
brlapi_initializeConnection symbol will no longer be in the
libbrlapi.so.  

We can use this incompatible binary change to our advantage, however:
upon detecting this failure, we can check to see if the BrlAPI Python
bindings are present.  This will give us a rough idea of which version
of BrlAPI is available (i.e., the one without Python bindings or the one
with Python bindings) and if Orca can get to it or not.  I just checked
in some changes to Orca's configure.in to do this, eliminating the
warning message if one or the other versions of BrlAPI is present.  

With respect to /var/log/Xorg.0.log, where would you suggest checking
for it with respect to XFree86_VT and WINDOWPATH?

Will

On Mon, 2006-12-11 at 11:17 +0100, Samuel Thibault wrote:
coscell mail batol net, le Mon 11 Dec 2006 17:54:34 +0800, a Ãcrit :
grep VT /var/log/Xorg.0.log

(--) using VT number 7

Ok. Please always check that.

William, I fail to see where the problem comes from. Does this warning
disable brlapi via the official python binding too?

configure: WARNING: Could not find libbrlapi.so - you need BrlTTY >= 3.7.2 and BrlAPI >= 0.4.1 installed to 
use braille

(the python binding itself seems to work fine: calling

import brlapi

from python works, and he says he doesn't get any error message from
orca)

Samuel




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]