Hi Laura,

   For Win32a,  I added the options of 64-bit chtypes,  allowing 21
bits for the character,  which covers all of Unicode.  (As well as
providing the additional bits needed to support attributes such as
A_DIM,  A_ITALIC,  A_OVERLINE,  etc. that don't fit in 32-bit chtypes.)
I think if you borrowed curses.h,  you'd have a decent start on
getting full Unicode in your SDL2 version.

   Win32a also allows for entry of hex or decimal Unicode via the
keypad (though this was only posted about five days ago!),  but
borrowing from Win32a might be a little more difficult here.  Still
probably worth checking,  though.

   BTW,  I have to agree with you on Wine overhead.  Wine is a lovely
solution,  in the sense that it's enabled me to take a lot of my old
Windows code and,  with only minor tweaks,  get it to run at full speed
flawlessly in Linux.  But it's a bit large.  Understandably so,  given
what it has to do,  but I'm still hoping this SDL2 solution pans out.

-- Bill

On 01/27/2015 07:23 AM, LM wrote:
I compared the demos using SDL1 and SDL2 with SDL2_TTF support.
Results are very similar.  Ran the clipboard test in testcurs and it
works very nicely with SDL2 clipboard support.  The biggest design
issue I see is Unicode support.  Looking through the code, chtype is
set by default to handle 16 bits for the attributes and 16 bits for
the character.  On Windows systems, wchar_t is also limited to 16
bits.  The testcurs ACS test shows some internationalized characters
when PDC_WIDE is set true.  However, I don't see any code to handle
anything beyond the first 16 bits of a Unicode character set.  So, for
full Unicode support, one would at least need to modify the size of
chtype and deal with wchar_t representing UCS-2, UTF-16 or UTF-32,
etc. depending on the platform.  Also, on Windows (Win32), one can
input non-standard characters via the keyboard using Alt and the
keypad keys.  It would be nice to have a similar mechanism that works
with SDL.  It's difficult to determine when a user hits Alt and 0 on
the keypad whether they want back the keypad character on the key down
event or whether they want what the next series of key-presses
converts to in a Unicode representation.  That makes it difficult to
code a solution to inputting Unicode characters that suits every case.


Reply via email to