From kde-core-devel  Wed Jul 07 12:23:20 2010
From: Thomas =?iso-8859-1?q?L=FCbking?= <thomas.luebking () web ! de>
Date: Wed, 07 Jul 2010 12:23:20 +0000
To: kde-core-devel
Subject: Re: [Kde-accessibility] focus tracking
Message-Id: <201007071423.21407.thomas.luebking () web ! de>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=127850552213994

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