Hi Samuel:
Samuel Thibault wrote:
Great!
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.
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.
BTW, I'm wondering how integrity may be ensured in AT-SPI: if an AT-SPI
reader calls getCaretColumn() and then getCaretRow(), how can one get
sure that the column hasn't changed in the meanwhile for instance (and
hence the reader should restart from the beginning)? (except checking
for signals).
AT-SPI clients MUST listen for signals, there is no other way. It's an
event-driven API, mostly. Even if there were a way to get the row and
column in one atomic operation, by the time you received the data it
could have changed, since there is no guarantee of synchronousness (and
can't be).
Bill
Regards,
Samuel Thibault
_______________________________________________
Accessibility-atspi mailing list
[EMAIL PROTECTED]
http://mail.freestandards.org/mailman/listinfo/accessibility-atspi
_______________________________________________
Gnome-accessibility-devel mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
