Dave Mielke <[email protected]> writes: > [quoted lines by Shérab on 2017/08/20 at 11:26 +0200] > >>I share Samuel's fear that is will be difficult to design something >>which is generic enough. What can we do beyond returning the keycodes >>themselves or brltty commands, as we currently do? > > What I suspect we need is a set of commands that reflect how one works within > a > graphical environment (perhaps things like hierarchical window navigation, > going to the navigation root window (home screen), going up one level, etc). > Then we could design key tables for that, and brltty (and via BrlAPI) could > be > used to naturally work within that environment.
I think we already have something like that, a predefined set of commands. The problem is, that we can not predict what a BrlAPI client actually wants to do. So we can make some assumptions about how a graphical screen reader works, but this will likely always be limiting to some types of clients (that might not even be written yet). Also, I am wondering how clients are going to implement their own bindings. JAWS for instance has an interactive key binding editor which is very nice for users. You can define a new binding for a screen reader command by simply pressing the desired key combination interactively. I am suspecting that some BrlAPI clients would like to do something similar at some point. Especially if the set of screen reader commands grows. Some of these commands might not be bound by default to anything, waiting for the user to customize a binding if they really need the command. If I haven't overlooked something, to me, what is missing is a way for the client to query the actual model the driver has detected. With that, a client could implement their own key code handling, because they actually would know what they can expect from a readKey call. The client would still need to do their own key code handling, which seems fine to me if what is desired is more control. Exporing our knowledge of how certain NavigationKeys are named could also help the client to avoid duplicating too much stuff. In any case, if we proceed with an attempt to generalize for graphical screen readers, we really should talk to Orca dev what they actually would want to have. They might have some insights that we haven't thought about yet. -- CYa, ⡍⠁⠗⠊⠕ _______________________________________________ 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://brltty.com/mailman/listinfo/brltty
