Re: [orca-list] "[window title] inaccessible": where does it come from, and what does it mean?

[Luca Saiu <lsaiu hypra fr>]

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