[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [Kde-accessibility] focus tracking
From:       Thomas =?iso-8859-1?q?L=FCbking?= <thomas.luebking () web ! de>
Date:       2010-07-07 12:23:20
Message-ID: 201007071423.21407.thomas.luebking () web ! de
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]