focus tracking
Gunnar Schmidt
gunnar at schmi-dt.de
Tue Jun 29 07:03:15 BST 2010
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: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100629/0dababe0/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-accessibility mailing list
kde-accessibility at kde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility
More information about the kde-core-devel
mailing list