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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.