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 _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
