[Bf-committers] International Input

[Ignacio Fernandez Moreno]

Hi all,

I've been researching too. My aproach was trying to get input in utf/unicode
and this is what i've found:

- Ghost gets every input as an ascci char, you can see this in
GHOST_TEventKeyData, and GHOST_EventKey. It should use wchar_t (from
wchar.h). I have a patch that does this and applies it to the rna. It
compiles and works giving some support to the utf input but it fails showing
it because there is format conversion in some places using RNA_string_get
with chars. Luckily ascii chars work well because they are the same in
unicode so until everything is changed this patch works in Windows. Unix and
OSX should change it's respective GHOST_System codes to set GHOST_EventKeys
with wchar_t instead of ascii but i'm not experienced with those yet.

So i the point is changing that in the GHOST_system of other OS and looking
where the RNA_string_get /RNA_string_set functions are called in the code
with char arrays and change them to wchar_t arrays, as i read in a tutorial
(can't remember address) a Character will no longer be a "char" in Blender
so everyone should be aware of that.

Maybe i have some point wrong or some code not really well implemented but
it's a start.

I've not looked into file saving/reading so our researchs are complemetary i
think.

The patch:
https://projects.blender.org/tracker/index.php?func=detail&aid=22112&group_id=9&atid=127

As i said, it needs some work. Specially I need help with the
X11/Carbon/Cocoa part.

2010/4/22 Yaohua Xiong <xiongyaohua at gmail.com>

> Hi Harley,
>
> > I haven’t notice anywhere that we’re using character strings that would
> include
> > anything outside of $00-$7F. Therefore we should be able to treat all
> strings as
> > if they *are* UTF-8. Those first 128 characters are the same and are
> > represented as a single byte. In other words, text strings that contain
> only
> > single bytes in the range $00-$7F are valid UTF-8.
>
> Well, some CJK encoding, for example GBK which is widely use in
> Mainland China, will use bytes range out of 0x7f. And these string
> will come from the interaction with OS, like filename and pathname.
>
> > For input our event loop (wm_event_system) needs a “translate_key”
> function to
> > replace “convert_key” where we can add platform-specific code to
> translate
> > keystrokes into characters based on the user’s input language and
> keyboard layout.
> > For Win32 this means using GetKeyboardState, MapVirtualKeyExW,
> > ToUnicodeEx, and then translating the result to UTF-8.
>
> I'm still not clear with the event handling, but I think we need to
> provide some basic IME aware funtions. For example only enable IME
> when text input field got focus, and disable it afterwards.
>
> > For Windows file operations we need to change “winstuff” to use
> FindFirstFileW
> > and FindNextFileW instead of the ansi versions. The results would have to
> be
> > converted from Wide to UTF-8.
>
> If change from the ANSI version of API to the Wchar version will not
> cause other side effects, I think this is the easy way. Because we
> don't need to worry about what encoding the result filename is in.
>
> Or maybe we can stick to the ANSI version API, it guarantees not to
> break other part of Blender. But this time we must determine what
> encoding the results are actually in. Then convert result into utf8
> accordingly.
>
> Regards,
> --
> Yaohua Xiong
>
> Traffic and Transportation Engineering College, Tongji Univ.
> Cao An Road 4800#, Jia Ding District, Shanghai,  China
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>