Edit: of course, i forgot the attachment script. My bad. On Mon, Nov 21, 2016 at 03:57:16PM +0100, Ksamak wrote:
I have made a script, relying on python-pyatspi, that can demonstrate an
example case of what i'm trying to describe.
This script is based on magfocustracker.py from the examples in pyatspi
project. It simply outputs the caret position and size, from atspi
events "object:text-caret-moved"
I'll describe a couple use cases that in my opinion are faulty:
- open firefox, type alt-d to go in address bar, then delete all text
in the field (backspace should suffice)
what happens => an event with 0,0 0x0 (no width/height, no position)
what should happen => an event with the caret size, placed at the
screen position of the caret.
note: behaviour is the same for any textarea, or entry in HTML
forms
- open a new, empty libreoffice-writer document, the caret is at start
of document.
what happens => an event with 0,0 0x0
what should happen => an event with the caret size, placed at the screen position of the caret.
- open a libreoffice-writer document, press return
what happens => an event with -1,-1,-1,-1 (it's the whole widget's position, we can ignore it)
an event with 0,0 0x0
another event with 0,0 0x0
what should happen => an event with the caret size, placed at the screen position of the caret.
note: one can write a paragraph, then press enter, the same
will happen
Tests have been made under debian mate jessie.
I think one can easily understand how a magnifier, tracked with this
would jump at random places of the screen, and be really confusing and
annoying for visually disabled people.
I'd be glad for any help you can think of to resolve this issue.
--
Ksamak
Free software hacktivist
-- Ksamak Free software hacktivist
Attachment:
buggy_caret_tracking_demo_script.py
Description: Text document
Attachment:
pgp1XWr18AcL9.pgp
Description: PGP signature