Re: [g-a-devel] AT-SPI, focus leaving and window IDs



Hi,

Bill Haneman, le ven 04 mar 2005 16:06:32 +0000, a dit :
> >>There is also the "active toplevel window", which is exposed through 
> >>"window:activate" and "window:deactivate" events.  So when an accessible 
> >>window becomes inactive, at-spi does send notification of this fact (via 
> >>window:deactivate).  So this information is already exposed by at-spi.
> >
> >
> >Ok, in my case (reading gnome-terminal's terminal widget), that wasn't
> >sufficient (since other widgets may get the focus).
> 
> I don't understand what you mean by "wasn't sufficient"... do you mean 
> that you weren't listening for "window:deactivate" events?

I'm not, because brltty doesn't care about toplevel windows, but only
about terminal widgets. I said "since other widgets may get the focus":
the user may open some menu, in which case the toplevel window is the
same, but the widget is different, and as such brltty should leave back
braille output control to gnopernicus.

> >>>- It would also be useful to be able to get widgets' X-window ID to
> >>>better handle focus.
> >>
> >>I don't see any useful thing that a screenreader on a _modern_ Xwindows 
> >>platform could do with this.
> >
> >Get the non-accessible application's window title.
> 
> I don't think this really works, because the window "title" (as seen by 
> the sighted user) isn't reliably available for 'inaccessible' 
> applications even if you have the XWindow ID.

Well, libwnck actually *does* rely on the XWindow ID.

But actually I wrote that "get title" reply way too fast. This is not
the point: what we need is at-spi-terms-reading-brltty to know the
underlying ID of the terminal widget, the one that is given to the
program running in the xterm in the WINDOWID environment variable.

The problem I'm seeing coming without that information is fbterm/screen:
For now, fbterm is not accessible, screen is via a shm hack. But on the
long term, I guess at-spi would be a good candidate to make them
accessible. However, how would BrlAPI be able to know which virtual
terminal currently has the focus if this it is not reported somewhere in
at-spi? The virtual terminal identifier needs be the same as the
WINDOWID environment variables given to applications, which give that to
the BrlAPI server when connecting.

> AT-SPI doesn't provide information about windows that don't
> participate in the accessibility APIs,

Yeah, that's fine, I don't need at-spi to give me such precise
information. Just underlying identifiers.

> For instance, a self-voicing application should still participate in
> at-spi so that it can work for mobility-challenged users, and so with
> focus-tracking magnifiers, etc.

Ok, I can understand that.

Regards,
Samuel



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]