On Tue, 17 Mar 2009, Dave Mielke wrote: > One profile per program? I doubt that works all the time because one program > can run another one, e.g. screen or telnet.
And this becomes a maintenance issue. > So let's design what brltty should support. Should we go the sbl route and > have > program profiles and attempt to figure out which program is currently > running? I'd avoid such avenue as much as possible. > Another possibility is to have a routing key based command which instructs > brltty to use the attributes of the selected character when searching for an > attribute cursor. Are there any other alternatives to consider? Explicitly identifying an attribute with a routing key is a good solution. However, in addition, I think BRLTTY could implement some heuristics to automatically determine the most likely attribute for that purpose. For example, if a menu selection bar scrolls down, then BRLTTY could observe an attribute swap in the vertical axis while the corresponding characters for those screen cells remain the same. And if there are more than 2 items in that menu, then determining which one of the two different attributes is the actual selection bar should be unambiguous as the third menu item which should be adjacent to the swap will be of the same attribute as the item prior the selection bar movement. Also, selection bars and colored cursor blocks should be easy to spot as they're represented by an attribute which occupies a small portion of the screen area. So a large contiguous area with the same attribute is unlikely to actually be that selection bar. So I'm sure we can come with a set of such heuristics that would cover a significant percentage of all cases without any special profile support. Nicolas _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://mielke.cc/mailman/listinfo/brltty
