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? See for instance the output of git grep -l processRoutingKey in the orca sources. Isn't this something that is working for years now? I mean, correct me if I am wrong but I thought it's not such a long time a2 is around and dealing with all the text fields, compared to Orca's ability to deal with routing keys. Unless there is a regression that happened in Orca and has somehow been masked? 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? > > 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. > 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? 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. > > > knows it brings better support in that case (the cursor routing you get > > > is achieved by the brltty core itself, not the a2 driver which is only > > > the "messenger"). > > > > But that is not what is supposed to happen when you click (use cursor > > routing keys) on links in Firefox, right? > > Ah, that part seems odd however, indeed. OK, I feel kind of relieved we can agree on this oddness, at least. ;-) > But again, which version of brltty are you using? 6.6-2 > > > So it's not really Orca that "depends" on brltty-x11, it's just that > > > brltty-x11 is an interesting complement to Orca, to improve screen > > > reading. > > > > I don't think it's fair to put things this way frankly. Currently, you > > simply can't read the screen in braille without brltty-x11... > > If that is so, it's a bug that needs a fix in Orca, and not just make > people install brltty-x11 as a workaround that we don't even understand > how it happens to work. Yes, I fully agree. Sébastien.
