[g-a-devel] Re: [Accessibility-atspi] AT-SPI enhancement proposal

[Bill Haneman <Bill Haneman Sun COM>]

Samuel Thibault wrote:

> ...
>
> Well, I guess that when not in double width mode, terminals can't handle
> doublewidth characters, so that the returned UTF-8 string will simply
> not hold any such character. And if it can, the returned UTF-8 string
> will hold some. Hence knowing whether doublewidth characters may appear
> seems useless: if they may, they will, and the reader handles them. Else
> they simply don't appear.
>
>  
I don't think this is the way it works, for Asian terminal emulators. 

> > setCaretOffset is allowed to return FALSE in the event that the request 
> > cannot be honored.
> >    
>
> Yes, but in the case of a terminal, the implementation will always be to
> return FALSE. So this calls doesn't seem to be useful.
>  
It is useful because it is required of all implementors of the Text 
interface.  Anything that places glyphs on the screen should probably 
implement Text, but not all such things have carets.

> > Even if there were a way to get the row and column in one atomic
> > operation,
> >    
>
> How can this be done?
>  
It cannot.  My point is that it wouldn't add much value if it could.

> > by the time you received the data it could have changed, since there  
> > is no guarantee of synchronousness (and can't be).                    
> >    
>
> Yes, of course, but at least you have a coherent pair of information.
>  
As long as you haven't received a caret-moved event in the meantime, 
your pair is coherent anyhow. 

Bill

> Regards,
> Samuel
>
> _______________________________________________
> Accessibility-atspi mailing list
> Accessibility-atspi mail freestandards org
> http://mail.freestandards.org/mailman/listinfo/accessibility-atspi
>