Yes it does, using the normal Microsofot keyboard layouts. Haven't you tried?

(It looks for WM_KEYDOWN/WM_KEYUP and not WM_CHAR/WM_UNICHAR because it needs to generate separate key up and down events.)

If you have a specific problem with some specific keys, some specific keyboard layout, or some specific uncommon way to input characters, please state that, instead of claiming that "Unicode input is not supported".

No, I would call that limited support for Unicode input.  GTK+ windows are not created as a Unicode window under NT4+ so any Unicode input support is just a kludge.

Does GTK+ support chained deadkeys?
Does GTK+ support ligatures? (as defined by Microsoft in keyboards)
Does GTK+ support extra shift states such as used by the Canadian Multilingual Keyboard (supplied by MS?)
Does GTK+ support planes 1-15? (requires ligatures, above)

All of these are defined Windows keyboard functionality in Windows NT 4+, and from what I can tell after a brief read of gdkkeys-win32.c it does not support these features.

Furthermore, by attempting to bypass and reinvent the Windows WM_KEY* - WM_CHAR design (however unfortunate it may be), you break forward compatibility (e.g. if MS extend the keyboard format in future), some handwriting and voice applications, enhanced input applications (such as Tavultesoft Keyman, which was the reason I was asked to pursue this issue), macro applications and more.  The method you have used will also most likely not work with the new Windows Vista keyboards such as Amharic (although I have not had the opportunity to test this).

At the very least, you should provide a fallback for WM_CHAR and/or WM_UNICHAR where characters received through this method generate a key down and key up event.  

Finally, if you are not using WM_CHAR, why are you calling TranslateMessage in your event loop?  Is it just for Alt+Space?

Do you have specific examples of what does not work?  gtk doesn't use the typical event translation functions because it must provide the same api & behavior as gtk on other platforms.  It something does not work, patches to make it work within the constaints of the gtk api would be much appreciated ;)

The developmnt branch (HEAD) of GTK+ (i.e., what will become GTK+ 2.12) *does* create Unicode windows, and uses the wide character versions of the message pump APIs. In HEAD I finally dropped all pretense of supporting Win9x. (In retrospect, this could have been done earlier, as GTK+ de facto has't run on Win9x anyway since 2.8 because of NT4+-only API in cairo.)

Sure, GTK+ could have done run-time checks also for the message pump APIs, like it does (did) for many other APIs, choosing between the wide character and "ANSI" versions depending on platform.

(You must realize that the amount of manpower working on GTK+ for Windows is very limited. I can spend a few hours per week on it currently, for instance. The more volunteers we get the better.)

You bring up valid points indeed. Some of these are known already. We have a bug open exactly for lack of interoperability with Tavultesoft Keyman (bug #129295), and I know that more complex keyboard layouts, even for some Latin keyboard like Czech, not to mention the Canadian Multilingual überkeyboard, is broken (bug #165385). Also bug #165723 is probably related. If we would have had somebody with your insight telling us these things earlier, there would have been a good chance these would have been fixed.

You must understand that the reason why we "reinvent the wheel" is because the GDK API exposes X11-like concepts like keymaps and separate key up and down events. The code in upper levels (GTK widgets) do rely on these. Just handling WM_UNICHAR would mean keymaps would have to be totally synthetic. Might work anyway, this needs testing.

I don't know why we call TranslateMessage(). Probably just inertia, as much earlier, gdk/win32 indeed *did* use WM_CHAR. Are you saying it shouldn't be necessary at all with the current code?

Would you mind answering some questions in private mail now and then, in case I decide to do something about this? Or would you prefer to join the gtk-devel-list mailing list and answer any questions I might have there?

Thanks for the helpful comments.

It sounds like you are heading in the right direction regarding Unicode windows etc.

I have had a look at writing a patch for WM_UNICHAR and WM_CHAR but setting up the GTK build environment for Windows is somewhat painful.

I can see two options:

A) Preserve existing functionality in GTK w.r.t. keyboard management.  The general direction I am heading for a minimal patch that will not break existing functionality (I hope):

1. Remove all references to TranslateMessage - it only generates WM_CHAR/WM_SYSCHAR

2. Special-case Alt+Space in WM_KEYDOWN/WM_SYSKEYDOWN to pump out a WM_SYSCHAR or WM_SYSCOMMAND; (another option: call TranslateMessage on WM_SYSKEYDOWN only).

3. Add a WM_CHAR handler that synthesizes a key down/key up event.

(WM_UNICHAR is not necessary as WM_CHAR will be Unicode anyway in HEAD)

B) Investigate how WM_KEYDOWN and WM_CHAR can be processed together in a way similar to Mozilla nsWindow.cpp (note: am currently working on a patch to fix a different bug there too).  I am not entirely clear on how the GTK keymap stuff works and what would be necessary to implement this but am happy to discuss.

I feel that option (B) would be safer in the long run as you avoid having to understand the keyboard layouts, but it would take more investigation/desing and definitely more testing to get it right.  It would address bug #129295, #165723 and #165385.

I am very happy to discuss with you on private mail (prefer not to join another mailing list at this stage).  Unfortunately I did miss bug #129295 when it was reported and was not informed of it by the bug reporter (pity).

> I am very happy to discuss with you on private mail (prefer not 
> to join another mailing list at this stage).

Sorry but that is completely against the principles of most Open Source developers. We much prefer discussions on public mailing lists. That way the discussions are archived, and other people who understand the issues can join in.

(Sorry, I have nothing new to say about the actual issue in this bug yet.)

*** Bug 521912 has been marked as a duplicate of this bug. ***

I add my comment as reponse to the following post:

http://mail.gnome.org/archives/gtk-list/2010-February/msg00148.html

To summarize: It is not possible to enter latin capital umlauts on a swiss
keyboard in windows in GTK applications (Notepad, WordPad, ... work as
expected).

In the following example I'll take the umlaut A as an example. A umlaut has the
following codes:

LATIN CAPITAL LETTER A WITH DIAERESIS = 196 = 0xC4
LATIN SMALL LETTER A WITH DIAERESIS = 228 = 0xE4

When I use Spy++ to watch the GTK application, I capture the following messages:

Swiss Layout

LATIN SMALL LETTER A WITH DIAERESIS

<00023> 0016056A P WM_KEYDOWN nVirtKey:VK_OEM_5 cRepeat:1 ScanCode:28 fExtended:0 fAltDown:0 fRepeat:0 fUp:0
<00024> 0016056A P WM_CHAR chCharCode:'00E4' (228) cRepeat:1 ScanCode:28 fExtended:0 fAltDown:0 fRepeat:0 fUp:0

LATIN CAPITAL LETTER A WITH DIAERESIS

<00026> 0016056A P WM_KEYDOWN nVirtKey:VK_OEM_5 cRepeat:1 ScanCode:28 fExtended:0 fAltDown:0 fRepeat:0 fUp:0
<00027> 0016056A P WM_CHAR chCharCode:'00C4' (196) cRepeat:1 ScanCode:28 fExtended:0 fAltDown:0 fRepeat:0 fUp:0

German Layout

LATIN SMALL LETTER A WITH DIAERESIS

<00172> 0016056A P WM_KEYDOWN nVirtKey:VK_OEM_7 cRepeat:1 ScanCode:28 fExtended:0 fAltDown:0 fRepeat:0 fUp:0
<00173> 0016056A P WM_CHAR chCharCode:'00E4' (228) cRepeat:1 ScanCode:28 fExtended:0 fAltDown:0 fRepeat:0 fUp:0

LATIN CAPITAL LETTER A WITH DIAERESIS

<00175> 0016056A P WM_KEYDOWN nVirtKey:VK_OEM_7 cRepeat:1 ScanCode:28 fExtended:0 fAltDown:0 fRepeat:0 fUp:0
<00176> 0016056A P WM_CHAR chCharCode:'00C4' (196) cRepeat:1 ScanCode:28 fExtended:0 fAltDown:0 fRepeat:0 fUp:0

For both keyboard layouts I used Caps-Lock to enter the "LATIN CAPITAL LETTER A
WITH DIAERESIS". On a german layout it is possible to use the Shift key aswell,
but on the swiss layout the shift key yields another character (which is correct
in GTK and non GTK applications).

*** Bug 690938 has been marked as a duplicate of this bug. ***

On reproducing bug #690938 I could reproduce the effect from Germany with the following settings: 
Operating system: Windows 7 (32 bit), Windows 8 (64 bit)
Input locale: DE (Deutsch (Deutschland) or Deutsch (Schweiz)) = German (Germany)/German (Switzerland)
Keyboard layout: Deutsch (Schweiz) 
Tested GTK+ 2 programs:
    on Win7: GIMP 2.8.2 , Inkscape 0.48.4 
    on Win8: GIMP master (2.9)

On pressing Caps lock and then Ä, Ö or Ü I got uppercase umlauts in an MS office application and lowercase umlauts in the GTK+ applications. 

Pressing " (=double quote) and then Shift + A, O or U gave me uppercase umlauts in GIMP and Inkscape, too. The " key is right next to the Ü key. You find more information at http://www.pctipp.ch/forum/showthread.php?t=6890.

Created attachment 256113 [details] [review]
Using WM_CHAR

This patch unfortunately will break some assumptions with gdk_keymap_translate_keyboard_state() if you're using that in your app, but in my opinion it's worth that trade-off.  In my testing so far it's worked well with different keyboard layouts, but I'd really like for others to test it with their keyboards and let me know how it works for them.

I've got a build of libgdk-win32-2.0-0.dll (this is gtk+ 2.x, not 3.x).  I can try to make a build of 3.x with this patch applied later if most people are using that on Windows now.

https://www.dropbox.com/s/0pyv38m2ij7xcjt/libgdk-win32-2.0-0.dll

I should have written a little more about the issue with gdk_keymap_translate_keyboard_state().

In a keyboard event handler, you may get evt->hardware_keycode set to 0 on Win32 with this patch.  This is because depending upon your keyboard layout some characters are the same hardware keycode, such as 'a' and 'ä' on US-International.  But if you're receiving 'ä' then it's already been translated, so you shouldn't try to pass it to gdk_keymap_translate_keyboard_state().  I don't understand how this translation stuff is setup well enough on Win32 yet, so instead I'm setting hardware_keycode to 0.  If someone else understands it and has a better suggestion I would love some feedback/help with how to improve this.

On Xamarin Studio we use this in key event handlers, so now we're checking if hardware_keycode == 0 then the event's key value can't be translated so we just use that value otherwise we use gdk_keymap_translate_keyboard_state().

Hello,

My first question would be : is the issue still around ? Taking for example :

(In reply to comment #10)
>On pressing Caps lock and then Ä, Ö or Ü I got uppercase umlauts in an MS office application and lowercase umlauts in the GTK+ applications.

With GTK+ master build (http://win32builder.gnome.org/ - CONTINUOUS_DEBUG zip archive), running "gtk3-demo.exe", selecting a random Entry demo, switching to German keyboard, pressing Caps Lock, Ö key, I get an uppercase umlaut.

But maybe the issue is different and wider than that, in which case I'd like to have a reproducible test case, using these binaries as a reference.

(In reply to comment #11)
Thanks a lot for your patch ! Unfortunately, it doesn't build against GTK+3, because "(GdkKeyboardGrabInfo) GdkDisplay.keyboard_grab" has passed private, and worse doesn't seem to be called anywhere else in the code (so I'd assume it is dead code).
I could investigate this, but I'd like an answer to my first question first.

Hello, 

I've tried the dll in dropbox and it seems that now the ESC key is no longer correctly handled.
Could you please build a new version where this is fixed? 

To reproduce install the latest Xamarin Studio open a combo box and try to close it with ESC. It will not work.

(In reply to comment #11)
> Created an attachment (id=256113) [details] [review]
> Using WM_CHAR
> 
> This patch unfortunately will break some assumptions with
> gdk_keymap_translate_keyboard_state() if you're using that in your app, but in
> my opinion it's worth that trade-off.  In my testing so far it's worked well
> with different keyboard layouts, but I'd really like for others to test it with
> their keyboards and let me know how it works for them.
> 
> I've got a build of libgdk-win32-2.0-0.dll (this is gtk+ 2.x, not 3.x).  I can
> try to make a build of 3.x with this patch applied later if most people are
> using that on Windows now.
> 
> https://www.dropbox.com/s/0pyv38m2ij7xcjt/libgdk-win32-2.0-0.dll

If you're using the latest Xamarin Studio, don't grab these builds.  Use the latest beta channel gtk-sharp installer (2.12.23 I think) which already includes this patch.  I just tested and ESC seems to work fine there.

(In reply to comment #15)
> If you're using the latest Xamarin Studio, don't grab these builds.  Use the
> latest beta channel gtk-sharp installer (2.12.23 I think) which already
> includes this patch.  I just tested and ESC seems to work fine there.

I just did an install a clean XS installation in a fresh Windows 7 virtual machine, switched to the beta channel, updated to XS 4.2.2 and gtk-sharp 2.12.23. The result is the same. German capital umlauts (like Ö) work but the ESC key only works if I press Shift-ESC. ESC alone does nothing. 

Can I help you to some how to reproduce the issue?

We should probably not use Gnome bugzilla for this discussion, do you think you could either post about the ESC issue on forums.xamarin.com or email me cody@xamarin.com?

I've cherry-picked this over to gtk-2-24 from master.

*** This bug has been marked as a duplicate of bug 704937 ***