Dave Mielke, le Thu 10 Jan 2008 09:34:38 -0500, a écrit : > [quoted lines by Samuel Thibault on 2008/01/10 at 14:15 +0000] > > >What made me think that is the definitions array in the openUsbPort > >function. The problem is that the guest screen reader is not > >necessarily brltty, it's possible that JAWS or WindowEyes requires the > >size and the USB ID to match. That said, the given possibilities (24, > >32, 40, 64, and 80) are numerous enough so that it's not so big a > >problem. We could hence have a "size-free" mode which uses the > >arbitrary display size, and a legacy mode which repects USB IDs and thus > >restricts the available sizes. > > We could always return the USB ID for the largest size <= the actual display > size. The length of the bytes written to the display could then be > appropriately padded so that as much of the display as possible is used.
Ok. > >Just the same: remember that the guest is not necessarily brltty, but > >could be any screen reader, so the key meanings must be generic enough. > >In the case of brltty, to get full support we could just use the brlapi > >protocol instead. > > The problem with keys is that each type of display tends to have a > fundamentally different layout so it may not be possible to map one display's > keys nicely to those of another. Yes, but I guess there are at least some basic keys which should be translatable in a generic way, like browsing arrows? Samuel _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@mielke.cc For general information, go to: http://mielke.cc/mailman/listinfo/brltty
