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

[Samuel Thibault <samuel thibault ens-lyon org>]

Hi,

Bill Haneman, le Tue 28 Jun 2005 13:37:39 +0100, a écrit :
> >I'm indeed not sure that isDoubleWidth would be useful: widths of
> >characters can be got from the unicode codes and they are not related to
> >the actual braille width anyway.
> >Where did that come from?
>
> Some asian terminal emulators (apparently) can operate in 'double width' 
> mode, in which the columns are computed according the the "normal" 
> doublewidth characters for that locale, and some characters are 
> halfwidth.  I don't know the details, will need to ask some i18n 
> terminal hackers.

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.

If it is intended for the reader not to insert doublewidth UTF-8
characters in the terminal, well there are many other encoding troubles
that could make the terminal refuse the input anyway.

> >I'm wondering what setCaret() can do in a terminal environment. How can
> >it interact with the running application to get the caret somewhere?
>
> 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.

> Even if there were a way to get the row and column in one atomic
> operation,

How can this be done?

> 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.

Regards,
Samuel