[Kde-accessibility] focus tracking

[Gunnar Schmidt]

Hello,

On Montag, 28. Juni 2010, Thomas Lübking wrote:
> tsts... didn't reply to all, sorry:
> -----------------------
>
> Am Monday 28 June 2010 schrieb Jeremy Whiting:
> > On Sun, Jun 27, 2010 at 4:28 AM, Jos Poortvliet
> > > KMag can zoom in nicely, but does not follow the focus of the cursor
> > > (only the mouse). This is a major issue. Does anyone know if it is
> > > possible to let it follow the cursor?
>
> > It is wanted that it follow the text cursor?  I don't think that would
> > be too hard but I doubt it's in there already.
>
> text cursors ("I-beam") are a completely client internal concept (esp.
> with non-native widgets or focus buddies) - to the server there are just
> some black pixels in a lot of bright pixels :-)
>
> Ie. it's known that some kbd input goes to a specific window, but how
> the window/application is gonna handle this input, including any visual
> feedback, is a "secret" to anything but the window/app internal logic.
>
> So to solve this for both and either, kmag or kwin, i don't think
> there's any way but adding some sort of protocol (like setting a
> property on the window about the "active I-beam" local position, the
> toplevel window with the input focus as well as it's geometry is public
> info) that still needs to be supported by the toolkits.

In fact, if you just follow the mouse cursor and the  text cursor, someone 
would come and ask about following the currently focused widget (even if it 
does not have a mouse cursor), so we need to also follow that.

On the other big desktop for Linux systems there are already two protocols 
which can be used to get these informations: Any program can use AT-SPI to 
get a lot of informations (e.g. the position of the text cursor and the 
position of the focused user element among other things) from the 
individual user applications, and a special magnification API is used for 
the communication between a screen reader and the magnifier (so that the 
screen magnifier does itself not need an AT-SPI implementation.

I am not sure if it is worth implementing some other protocol in the 
meantime as an interim solution until AT-SPI2 is mature enough to be used 
by KDE applications.

Gunnar Schmidt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-accessibility/attachments/20100629/0dababe0/attachment.sig