From: Thomas Lübking <thomas.luebk...@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 (apinhe...@igalia.com) _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
