[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Accessibility] Re: [Kde-accessibility] focus tracking

From: Thomas Lübking
Subject: [Accessibility] Re: [Kde-accessibility] focus tracking
Date: Wed, 7 Jul 2010 14:23:20 +0200
User-agent: KMail/1.13.5 (Linux/2.6.34-ARCH; KDE/4.4.5; i686; ; )

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.

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.
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 

*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 ;-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]