CocoMUD client

I didn't know about these problems.

Unfortunately I cann't test it because I don't have a braille display nor a JAWS installation.

Do you know a way to emulate a braille display?

I don't really know how it could work. But from what I'm reading on wxPython, it seems there's no easy solution to that problem anyway. Best case scenario: it's a bug individual screen readers will have to fix. I had wanted to implement a beautiful solution but all the methods on wx.TextCtrl that change contents also play with the cursor. I would really appreciate other accessible alternatives to wxPython, and it's not the first time I think about it. But I'm willing to admit on Windows this is the best I've seen for accessibility.

Hi again,

Then the Append function of the TextCtrl control still changes the entire value of the output?

Cheers,

That is correct. Your strategy may be more optimized in the end, perhaps wxWdigets realize most of the text you wish to change is the same. For some unknown reason, I wasn't able to find a method that didn't change the cursor position (the cursor goes either at the beginning of the end). So I don't see an immediate solution to this problem. We'll let this issue open but Sprint 16 won't include it anymore, there are still open issues to close before Saturday!

Just a thought however. I wanted to find something that didn't move cursor position. Well, it's not possible. But I guess we could take advantage of it...

What we do right now, basically, is to clear the window each time new input is received. This is probably costly and players have reported lags when the window becomes too big (hence the option to erase the output window content as a temporary solution). Instead, I suggest that we only append the text to the bottom of the window. This would require to:

1. Move to the end of the window (that is, the editing position).
2. Save the text between the editing position and the end of the window (the user could have written something).
3. Use AppendText to only append the text that has been received.
4. Move the cursor back where it was, since the position is still valid. If the cursor was beyond the editing position, a little calculation will be necessary to determine the new cursor position.

This simple solution was disregarded because it forces the cursor position to update with no compromise. But since the cursor position will change no matter what, why bother?

A note here: it might be very efficient for the window without rich-text. But for a rich-text, an additional concern arises: when using AppendText, is the style preserved? If so, we could really optimize both windows.