On 2015-06-29 at 13:00, Joanmarie Diggs wrote: > Therefore, if you > could file a bug against Orca and attach a full debug.out, I'll look > into it. Thanks!
Thank you. And thanks for your response about Braille as well. The idea of looking at the Orca log helped me to understand a few things [1], and showed me that perhaps I'm not as so far from the solution. Yesterday I noticed a behavior I couldn't initially reproduce: sometimes the text contained in my AtkText component *did* appear in the brltty virtual terminal. After playing with the thing randomly for a while I understood that the text showed up when my window was already existing and focused at the moment Orca started up. Switching to the window later doesn't have the intended effect, nor does firing up my program with Orca already running. I'm not opening an Orca bug report (unless you want me to) as I don't really think this is a problem with Orca. However I uploaded a copy of the logs to my personal web site: http://ageinghacker.net/a11y-scratch/ This is what I did: * I started brltty with its X11 driver: $ nohup /sbin/brltty -b xw -x a2 -A auth=none,host=$DISPLAY &> /dev/null & * I kept a terminal window always open, from which I started Orca (otherwise, starting it via ssh as I normally would, Orca got difficult to kill with SIGINT or even SIGTERM, thus truncating the log; that's not important now) like this: $ killall -KILL orca; rm ~/orca.log; sleep 3; echo START; ~/usr-orca/bin/orca --disable=braille-monitor --enable=braille,speech --debug-file=/home/luca/orca.log --debug --replace The delay gave me time to focus on another window before Orca starts. * I started the test program via ssh, either before or after Orca. * With the test program focused, I pushed <keypad 6> once to read the current text. * I switched back to the terminal and killed Orca with SIGINT, so that it can save the log. I used my test program, and a simple GTK+ 3 program whose accessibility works fine: just one window containing just one label. My program is supposed to contain a root object named "the-root-object", itself containing a window named "the-window", partially implementing the AtkText interface (I'm now considering to use AtkObject.get_name instead, which should be simpler, but that's another story) and displaying the text "this-might-even-work-if-i-am-lucky". My test program emits ATK signals in a messy way; I only understood the correct way to use them last night [1]. The problem may indeed be that: there's probably some AT-SPI notification my program is not emitting when it should. However, for some reason, if Orca fires up with the program window already focused it can successfully read its text. <keypad 6> never has the intended effect in my application. With a GTK+ application it works, but only if I start it *after* Orca; if I start the GTK+ program before Orca, the frame name is read correctly, but the label shows up as a blank line. <keypad 6> works nicely if I switch back to the terminal and then to the GTK+ window again. This is nitpicking and probably already out of spec, but might be relevant with respect to my program as well, since right now I have to start it before Orca. (as another very minor point, brltty is clever enough to continue working after I kill Orca, correctly displaying a terminal line; but this does *not* work for other GTK+ programs such as my window-with-a-label test. This confused me in the beginning, but I'm completely sure that Orca has nothing to do with it. ps -A | grep orca showed nothing.) My current SDL/ATK test, also derived from the AT-SPI2-ATK testsuite, is very messy but I can publish that as well if you want; of course I won't ask you to fix it for me. Maybe my logs are already enough to see what the problem may be, to your expert eye. What I am missing? Shall I emit some ATK signals I'm currently forgetting at some point? Thank you very much for your help, and for your work. [1] http://osdir.com/ml/debian-accessibility/2015-07/msg00000.html -- Luca Saiu HYPRA -- Progressons ensemble : http://hypra.fr -- To UNSUBSCRIBE, email to debian-accessibility-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4j03qqc....@hypra.fr
