[Kde-accessibility] focus tracking

[Piñeiro]

From: Thomas Lübking <thomas.luebking at web.de>

> Not questioning orcas (assumed?) heuristics, but QApplication has a 
> focusChanged( QWidget * old, QWidget * now) SIGNAL as well as focusWidget()
> 
> So there should be no need for guessing around on the Qt side.

Just guessing, but probably this focusChanged signal is the one used
on Qt world to report AT-SPI about the focus change. Continuing with
the guessing, used on qt-bridge implementation.

> KApplication could simply bind the SIGNAL to a SLOT setting the focus widget 
> area on some magnification server.

So this thread is searching for a common way, or common language, to
track the focus in a magnification tool, in this case using at-spi,
but, do you want to bypass at-spi and made a direct comunication
between a Qt app and the magnification tool?

Because yes, probably Orca is implementing some heuristics. But this
heuristics are based in the information provided by AT-SPI.

> (And with a little smartness, calculate the exact position for some standard 
> widgets like line- or textedits, maybe one can have a dynamic property used by 
> eg. kate/konsole parts to support this)

As Joseph explained, this "little smartness" are the heuristics
implemented in Orca.


> 
> Thomas
> 
> Am Tuesday 06 July 2010 schrieb Joseph Scheuhammer:
>> Hi all,
>> 
>> On 01/07/10 3:53 PM, Jos Poortvliet wrote:
>> > Ok, thanks all for the responses. A couple of questions if you don't
>> > mind, to check I understand this properly: - AT-SPI does not have a way
>> > of tracking focus for magnification purposes? - So Gnome-Mag has
>> > developed an API for this, but it's currently CORBA based and thus needs
>> > changing - apps need to support this API for magnification to properly
>> > work
>> 
>> Here is my understanding.
>> 
>> AT-SPI has a way of tracking focus, yes, but not specifically for
>> magnification.  There are focus events that can be listened for, and, I
>> believe, one can use AT-SPI to query where focus is.  The result is
>> sometimes in terms of a GTK+ widget, in the sense that AT-SPI tells you
>> that a specific widget has keyboard focus.
>> 
>> Gnome-mag has not developed an API for focus tracking per se.  Gnome-mag
>> *is* a CORBA service, and is being ported to a DBus service.  All
>> services have an API so that other processes can make use of them.   One
>> of the functions the magnifier service provides is along the lines of
>> "given these screen coordinates, place the centre of the magnified view
>> at that point".  By itself, this function doesn't know anything about
>> focus. However, something that does know where focus is can determine
>> the relevant coordinates and tell the magnifier where to place its
>> view.  (Aside:  gs-mag also implements the same DBus service).
>> 
>> What is the something that knows where focus is?  As far as I know, the
>> only application that computes this is Orca.
>> 
>> And now for some historical background:  when I started the
>> implementation of a magnifier within GnomeShell, my intent was to use
>> AT-SPI to track keyboard focus, and have the magnifier update its view
>> accordingly.  I proposed this to Will Walker, the lead Orca developer at
>> 
>> the time.  His response was (my emphasis):
>> > So, we could deep dive on this whole thing and duplicate what Orca is
>> > doing in Python to track the notion of "focus", but in Javascript,
>> > requiring you to learn a whole new technology, a whole new API, and
>> > *re-solve all the same problems Orca has solved*.  Or, you could
>> > expose a simple API, which will be needed anyway, and let Orca do the
>> > driving. ;-)
>> 
>> In other words, Orca is tracking keyboard focus.  Furthermore, my
>> impression is that Orca is doing something above and beyond what AT-SPI
>> provides; that Orca uses a host of heuristics for focus tracking.
>> What's happening is a sequence like this:
>> 
>> 1. User moves keyboard focus.
>> 2. Orca uses AT-SPI and Orca's own built-in heuristics to determine the
>> region on screen that contains the focussed element.
>> 3. Orca instructs the magnifier service to update its view given the
>> coordinates of that region.
>> 
>> In summary, the magnifier is pretty dumb when it comes to keyboard
>> focus.  The genius here is Orca.
>> 
>> In closing, here is something of a proposal:  the machinery that Orca
>> uses to track keyboard focus is not inherent to a screen reader.  Other
>> processes could well make use of Orca's focus tracking machinery.  It
>> would be very useful if these heuristics could be carved out of Orca and
>> published as a separate module, library, or service that any process
>> could make use of.
>> 
>> Hope that helps.
> 

===
API (apinheiro at igalia.com)