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

Ksamak <[email protected]> Wed, 16 Nov 2016 09:32:20 +0100

Newsgroups	gmane.comp.gnome.accessibility.general
Message-ID	<[email protected]>

On Tue, Nov 15, 2016 at 07:49:00PM +0100, Samuel Thibault wrote:
> Hello,
> 
> Ksamak, on Tue 15 Nov 2016 16:52:51 +0100, wrote:
> > 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 looks like a bug to me.
> 
> > Another similar problem is when a text is empty, thereby no text
> > offset is present.
> 
> Ditto.
> 
> > I know these behaviours are probably correct according to AT-SPI
> > standard,
> 
> What makes you think that?
Well, i think there might be a reason for such a behaviour. I can
imagine the orca screen reader wanting to ignore an empty line for
example.
> 
> > but is it voluntary?
> I don't think it is. Probably just nobody ever had the need for these to
> be fixed.
> 
> > Is it possible to change any of that in the future, without impairing
> > the other applications relying on at-spi?
> 
> My guess would be yes. I don't see how useful it'd be to get 0,0
> coordinates while the caret is obviously not at 0,0.
Well, I was thinking the design was not thought through for visual
applications. There is indeed no thickness to report for a caret that is
on a newline.
Anyway, if it doesn't disturb any other applications, i'd be glad to see
that part change!
thank you
-- 
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)