Re: focus tracking
Thomas Lübking <[email protected]>
| Newsgroups | gmane.comp.kde.devel.accessibility,gmane.comp.gnome.accessibility.general,gmane.comp.kde.devel.core |
|---|---|
| Message-ID | <[email protected]> |
Am Wednesday 07 July 2010 schrieb Martin Sandsmark: > On Wednesday 07 July 2010 11:21:25 Piñeiro wrote: > > As Joseph explained, this "little smartness" are the heuristics > > implemented in Orca. > > If I understood Thomas right, the "little smartness" is highly widget/app > specific, and therefore doesn't make sense to try to have outside of the > widget toolkit/application. Indeed. Think of a mix'd kwrite window. Nearby the entire screen is covered by the focus'd widget, but only the client process (kwrite) has any reliable* chance to determine the exact position of the I-beam. Better: it even quite knows *why* the focus has been given, allowing you to prevent nasty jumps when sth. just grabs focus programatically. A 3rd prcocess could maybe diff the frames and match that against the focus'd widget reagion, what would dramatically fail when kwrite highlights barackets etc. *except for doubling headers, inspecting the process memory, looking for class footprints, pray for matching ABI and reinterpret_cast'ing the relevant portion - of ref'd stack, in doubt ;-) On Wednesday 07 July 2010 11:21:25 Piñeiro wrote: > do you want to bypass at-spi and made a direct comunication > between a Qt app and the magnification tool? No - I did not intend to suggest bypassing AT-SPI, I didn't mean to talk about protocols at all. I just wanted to point out that there's a better way to track focus than relying on (unspecified) heuristics of a foreign process. (and in that not even intended to offend Orca - it might be required for Gtk+ - dunno ;-) Cheers, Thomas