[Kde-accessibility] focus tracking

[Thomas Lübking]

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.

KApplication could simply bind the SIGNAL to a SLOT setting the focus widget 
area on some magnification server.
(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)

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.