Re: AT-SPI standard's management of text objects

Ksamak <[email protected]> Mon, 21 Nov 2016 15:57:16 +0100
Newsgroups	gmane.comp.gnome.accessibility.general
Message-ID	<[email protected]>
On Tue, Nov 15, 2016 at 04:52:51PM +0100, Ksamak wrote:
> Hi,
> When caret is on a newline, it is quite hard to get the
> screen position of the newline caret, The function atspi_text_get_character_extents
> is of no help, and returns 0,0 as coordinates when such offset is
> provided.
> This makes it really hard to track for a zoom without consistent
> workarounds.
> 
> Another similar problem is when a text is empty, thereby no text
> offset is present. The zoom area should then be on the caret, so one can
> see one can start typing.
> However, is it to my knowledge impossible to get a character extents, or
> a caret position/size of some kind. The workaround is to extrapolate the
> position of the beginning of the paragraph/text, which gives mediocre
> results.
> 

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

_______________________________________________
gnome-accessibility-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
signature.asc (application/pgp-signature, 801 B)