Sébastien Hinderer, le lun. 04 sept. 2023 22:02:48 +0200, a ecrit: > Samuel Thibault (2023/09/04 21:28 +0200): > > Sébastien Hinderer, le lun. 04 sept. 2023 21:16:47 +0200, a ecrit: > > > Samuel Thibault (2023/09/04 21:01 +0200): > > > > So the behavior you expect is not actually implemented by Orca, it's the > > > > a2 screen driver that takes precedence in the text fields > > > > > > Well I am unsure about what you mean by text field here because, for the > > > little of GUI I am using (Firefox essentially), I have observed this > > > behaviour or not being able to use braille window navigation and routing > > > keys in a very constant way. Is any place in a web page really a > > > text-filed? > > > > Yes. Or more precisely: they all expose a text interface, even if they > > don't have a text role. Since apparently orca doesn't capture routing > > key events, these events fall back to being exposed to the a2 driver, > > which gives it to brltty, which uses a2 to read the widget content, and > > perform the cursor routing. > > Are you sure Orca does not deal with routing keys?
I don't mean it's not implemented. I mean in the tests one can make, Orca doesn't happen to be doing anything with them. For *whatever* reason that might lie between the actual braille device and Orca. > Isn't this something that is working for years now? I have no idea about that, as I don't actually use Orca. > Unless there is a regression that happened in Orca and has somehow > been masked? Or in whatever is between the device and Orca. > Even theprecedence mechanism is not that old, probably newer than a2 > and thus even if a2 is there for a long time it's not such a long time > it cantake precedence over Orca when there are widgets they both know > how to render, right? Without actually taking the time to actually *inspect* what is happening, I'll just stop making any more guesses, it's a loss of time from all of us. > > > Also, if the a2 screen driver "just" takes precedence, shouldn't things > > > still work when it's not there? > > > > If Orca was capturing routing key events, yes. It appears that doesn't > > happen. > > That's a real surprise to me. Yes, but that's a fact: in my test it doesn't print any log upon routing key press. > > In the test I made with Roberto's case, it really was brltty's way of > > pressing arrows to simulate routing, that Orca doesn't implement > > anyway. > > In which context (applicaiton, widget) did you test? Routing key in pluma. > Intuitively, I'd have assumed that indeed orca is not simulating arrow > key presses as brltty does but that it rather implements the routing by > simulaitng moves of the mouse ppointer, and mouse clicks. > > In particular, I was under the impression that, in fFirefox, when I am > "clicking" on a link with the cursor routing keys, it's really like if I > was doing a mouse click. Ok, but what I saw was definitely brltty's routing, for whatever reason that might happen to be. > > But again, which version of brltty are you using? > > 6.6-2 So when brltty-x11 is not installed, you do not have a second brltty running, right? Samuel
