System keyboard layout is ignored on Windows

[adrientetar]

FontForge always uses QWERTY apparently.

cc @jtanx

[jtanx]

A quick look at this suggests that it must be set when the X server is launched, e.g. the cygwin build suggests to add (for the Japanese keyboard)

-xkbmodel jp106 -xkblayout jp

So for my builds, that would mean editing this line in fontforge.bat

start /B "" "%FF%\bin\VcXsrv\vcxsrv.exe" :9 -multiwindow -clipboard -silent-dup-error

This document seems pretty good at explaining the xkb layout and models that need to be set. The file in bin/VcXsrv/xkbdata/rules/base.lst lists all models and layouts that it supports.

I don't know how to automate this based on locale though.

[adrientetar]

@jtanx Do you know of a working setting for #1908?

[jtanx]

Not at this stage no.

[jtanx]

Okay, so I did some testing a while back, and it turns out that it's not an issue from VcxSrv. I was able to get VcxSrv to correctly work with a different keyboard layout (can't remember the settings right now) using another program like gedit, but using the same keyboard layout with FontForge does not work.

I narrowed it down to the call to XLookpString in gxdraw.c returning a zero-length response, hence the keyboard not working. I believe it is an encoding issue, but I don't really know that much about Xlib to know what's going on here. I haven't gotten much further than that at this point.

[jtanx]

I've been able to work on this some more. So there were a few things that needs fixing:

1. I was compiling libX11 without xlocaledir from environment variable support (--enable-xlocaledir)
2. The locales bundled with VcXsrv (locale.alias) were for some reason missing the locale names (e.g. English_Australia.1252)
3. Not all controls use an input context (e.g. on creation of a text box, should specify gg_text_xim in the flags)

That last point is what prevents it from working fully. E.g. in the file open dialogue, you can't type anything with a non-standard keyboard, but in the font view, you can use it just fine because there's an input context.

A hack would be to check if ((GXWindow) gw)->gic is NULL (here) and if so, to create an input context then (so that it uses Xutf8LookupString instead of XLookupString). This works, but then I don't know why an input context isn't created all the time. E.g. is there any case where an input context is not needed or wanted?

[jtanx]

Actually, it looks like at present only the open font dialogue is affected. And in any case you can't open files containing non-ascii characters on Windows (in FontForge) right now anyway. So it might actually be okay as it is. Hmm...

[jtanx]

I have a test build for anybody that wants to try - see #2065 and #2156 for example configurations. I've been able to test with Russian and French keyboard layouts (on-screen keyboard testing) but I guess nothing beats having people test it with actual keyboards.

I haven't been able to get Japanese layout to work though (moreover I don't know how this would work anyway).

[adrientetar]

It works for me, nice. I did not need to change configuration.

[adrientetar]

Open dialog also seems to work for me.

[jtanx]

I think it is codepage (of your Windows configuration) dependent. E.g. On mine it won't work presumably because somewhere along the path it tries to encode it using my codepage, which only supports English/ASCII characters.

[davelab6]

Nice! I'm hoping Frank will cut a release next week so this will make a big difference for this release :)