Bug 4205 - Incompatible with United States-International keyboard layout
Summary: Incompatible with United States-International keyboard layout
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Text Editor ()
Version: 2.9.x
Hardware: PC Windows
: High normal
Target Milestone: ---
Assignee: Cody Russell
: 7306 10981 11629 16266 16330 16464 ()
Depends on:
Reported: 2012-04-03 08:50 UTC by Shawn White
Modified: 2013-12-18 09:26 UTC (History)
14 users (show)

Tags: gtk
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Shawn White 2012-04-03 08:50:45 UTC
It's not possible to type the dead keys (",',`,~,^) when using the US-International keyboard layout. The normal way to type these characters using this layout is to hit the key and then hit spacebar immediately afterwards. In MD this just results in a space.

More about the layout: http://en.wikipedia.org/wiki/Keyboard_layout#US-International

ps. This is happening in 2.9.3.
Comment 1 Mike Krüger 2012-04-03 09:59:13 UTC
It's not exactly the same as 3680 - but it's too windows dead keys.
I don't think that we'll be able to fix that anytime soon. 
Not until we shift away from GTK - we share this problem with all GTK windows applications.

*** This bug has been marked as a duplicate of bug 3680 ***
Comment 2 Mike Krüger 2012-04-03 10:27:07 UTC
regression from 2.8.x
Comment 3 Mike Krüger 2012-04-03 11:29:39 UTC
Works with current newresolven on windows 7.
Comment 4 Mike Krüger 2012-04-27 06:21:32 UTC
At least I can repro that hitting 2 times " doesn't result in a " with EN international.

+ On some systems the layout is more broken. (even if some of these keys above for me worked, they don't do it on all systems)
Comment 5 Miguel de Icaza [MSFT] 2012-04-27 12:56:28 UTC
Request: can we isolate dead-keys not working on the general text editor, from dead-keys not working on a standard Gtk+ widget?

I would like to figure out which problems are caused by Gtk, and which ones by our custom data entry.
Comment 6 Felipe Cypriano 2012-10-10 14:05:11 UTC
I'm having problems with double quotes and ~ characters. I'm using Mac OS X 10.8.2 and MonoDevelop

When I type SHIT + ' + space I get this char ˝ instead of the correct one "

When I type SHIFT + ` I get this thing  instead of ~

The others dead-keys ', ` and ^ are working.

Is there an ETA on this issue? Since I'm on a Mac and can't use Visual Studio this is a pretty serious problem.
Comment 7 Aleksander Morgado 2012-11-23 08:44:31 UTC
I've tested the issue using:
 * Windows XP in US-International
 * latest MD (3.0.5) with gtk-sharp 2.24.10
 * gtk-demo included in the gtk+ bundle for version 2.24.10

The differences between the two are:

  ~          ---> Works in gtk-demo, not in MD
  ~ + n = ñ  ---> Works in gtk-demo, not in MD
  ^          ---> Works in gtk-demo, not in MD
  ^ + a = â  ---> Sometimes works in gtk-demo, never in MD
  " + e = ë  ---> Works in gtk-demo, not in MD
  c + ' = ç  ---> Doesn't work neither in gtk-demo nor in MD
  ' + a = á ----> Sometimes works in gtk-demo, never in MD
  ` + a = à ----> Sometimes works in gtk-demo, never in MD

When I say that sometimes works in gtk-demo is because it's not really reliable; sometimes you press the combination and works ok, sometimes it doesn't.

In MonoDevelop it seems that none of the combinations works.

I tested all combinations in Notepad just to make sure and they all work nicely there.
Comment 8 Aleksander Morgado 2012-11-27 07:13:00 UTC
As mitch pointed me out, this is of course wrong:
  c + ' = ç  ---> Doesn't work neither in gtk-demo nor in MD
Should have been written:
  ' + c = ç  ---> Doesn't work neither in gtk-demo nor in MD
(of course)
Comment 9 Aleksander Morgado 2012-11-27 07:21:49 UTC
Once switched gtk-demo to using IME input method, the issues from MD can now be reproduced directly, so:

  ~          ---> Works with Simple IM, not with IME
  ~ + n = ñ  ---> Works with Simple IM, not with IME
  ^          ---> Works with Simple IM, not with IME
  ^ + a = â  ---> Sometimes workswith Simple IM, never with IME
  " + e = ë  ---> Works with Simple IM, not with IME
  ' + c = ç  ---> Doesn't work neither with Simple IM, nor with IME
  ' + a = á ----> Sometimes works with Simple IM, not with IME
  ` + a = à ----> Sometimes works with Simple IM, not with IME
Comment 10 Aleksander Morgado 2012-11-29 09:30:47 UTC
So, the outcome of this is the following.

IME input method is totally useless unless you actually have an IME installed, which you only do if you require e.g. east asian languages, which come with per-language IMEs.

When switching to the Simple input method, all dead key combinations work as expected, except for the cedilla one (which has its own input method 'imcedilla').

So the best fix here would be to default in MonoDevelop to using IME only on e.g. Chinese or Japanese locales, and otherwise use the Simple input method.
Comment 11 Mikayla Hutchinson [MSFT] 2012-11-29 19:11:18 UTC
So... we'd need to detect input language changes (*not* locale), and change the GTK IME across all realized widgets? It's not particularly unusual AFAIK for users to have the input language toolbar enabled and switch input languages as they enter different kinds of text - there' even a keyboard shortcut for it.

TBH this sounds like a bug in the GTK IME module, this kind of thing should be transparent. Shouldn't the IME module fall back to Simple if there is no active Windows IME?
Comment 12 Mikayla Hutchinson [MSFT] 2013-04-08 18:29:26 UTC
*** Bug 10981 has been marked as a duplicate of this bug. ***
Comment 13 Mikayla Hutchinson [MSFT] 2013-04-08 18:30:31 UTC
*** Bug 11629 has been marked as a duplicate of this bug. ***
Comment 14 Aleksander Morgado 2013-05-14 11:08:00 UTC
I've been checking this issue again in the past days. The current situation is the following:

 * Windows XP without East Asian Languages installed cannot use IMM/IME, all the IME specific API methods will fail. GTK+ could detect this and completely avoid loading the IME input method module in this case, as it is completely useless.

    if (!GetSystemMetrics (SM_IMMENABLED))

 * Windows XP with East Asian Languages, or newer Windows versions, have both IMM support available (and enabled) always, regardless of the locale being used.

Now, unless there is a given input method forced to be used, GTK+ tries to automatically assign the best input module based on the *system locale*. In the specific case of the IME input method, it will be the default for the whole GTK+ application if the system locale is either Japanese (ja), Korean (ko) or Chinese (zh). Other defaults are equally applicable, e.g. if system locale is Catalan (ca), the special 'Cedilla' input module is chosen.

System locale can be changed (e.g. Win7) through the following sequence (reboot required):
  Control Panel
    Region and Language
        Language for non-Unicode Programs
          Change system locale...

The problem with this behaviour is that changing the *default input language* (e.g. from English to Japanese+IME) doesn't affect the GTK+ application. Therefore, I can have an English system locale (where GTK+ will choose Simple IM by default) but then have Japanese+IME as input language.

Default input language can be changed (e.g. Win7) through the following sequence (no reboot required):
System locale can be changed (e.g. Win7) through:
  Control Panel
    Region and Language
      Keyboards and Languages
        Keyboards and other input languages
          Change keyboards...

So a good solution would probably be to listen to WM_INPUTLANGCHANGE messages and change the default IM within GTK+ automatically. Or, if that is too hardcore, at least use GetKeyboardLayout() to gather which the default input language is at program startup and use it to decide which IM to use...
Comment 15 Miguel de Icaza [MSFT] 2013-05-14 11:53:20 UTC
I am perfectly fine only supporting Windows7 and better for international support, I do not care about XP for that scenario.
Comment 16 Aleksander Morgado 2013-05-16 04:44:49 UTC
Upstream bug report here:

Still, changes to the input language during the program run are not considered in the suggested patch; will do that if the change is accepted.
Comment 17 Mikayla Hutchinson [MSFT] 2013-05-16 17:53:30 UTC

Alan, could we add this to our patchset?
Comment 18 Carlos Garnacho 2013-07-26 12:12:00 UTC
In comment #11:
> TBH this sounds like a bug in the GTK IME module, this kind of thing should be
> transparent.

I do agree with that impression. Aleksander's patch still does help at choosing a better default, although performing live changes would be a behavioral change I'm a bit wary about. But the root problem here is that IME doesn't behave nicely on a valid setup. I've reported a new bug upstream:


The patch there adds builtin handling of dead keys in the IME input method, as apparently IME doesn't cope that well with non-spacing characters, and delegating on the simple input method turned out to be mildly complex around state propagation and the very specific situations we want it to kick in.
Comment 19 Rogier van der Hee 2013-09-04 09:31:54 UTC
Perhaps related: there is a bug that copy-paste from the clipboard generates an error in Xamarin Studio, and that is also resolved by setting the keyboard to US instead of US Int. Couldn't find the appropiate bug report related to that, but good chance if you solve this bug upstream, the copy paste error will be resolved as well.
Comment 20 Cody Russell 2013-09-13 23:11:37 UTC
I've put a patch into our OpenSuse build service which appears to fix the issue with US-International keyboard in my testing, and I'm hopeful that it may fix the issue with other keyboard layouts as well.

I'm generally not familiar with all the different keyboard layouts, so I'd love it if some people who use US-International and other layouts would grab the build and test it out.

Link to the build service page:

The basic gist of this, though, is that we shouldn't be inserting character events when we get WM_KEYDOWN and WM_KEYUP, we should be inserting those events when we receive WM_CHAR.  We should be using WM_KEYDOWN and WM_KEYUP for non-character input (arrow keys, etc).

There's still a little bit of hackiness in the patch that I'll try to fix, but it seems to be working well for me so I'd like to get some people to test it if possible.
Comment 21 Cody Russell 2013-09-16 16:53:11 UTC
Here is a build that seems to be working well for me.  If Shawn and anyone else having problems can find time to test this, it would help very much:


Put this into C:\Program Files (x86)\GtkSharp/2.12\bin

(backup the file in that directory first, just in case)
Comment 22 Rogier van der Hee 2013-09-16 17:19:23 UTC
Just tested on Win8 in Beta channel (4.0.12 build 3), with standard US-Internatioal keyboard and layout and copy-paste is working now as well as some of the special characters. Single quotes work now as intended: <"/'>-Space now inserts only a single quote.

Still, double quote is not working as intended: Normally, I have to press Shift-<"/' key>-Space to insert it (if you enter a char key you get some special characters such as ë). 

It is difficult to pinpoint but occasionally the double qoute insert works, but most of the times it is not. Luckily, you don't need that very often while programming :-).
Comment 23 Rogier van der Hee 2013-09-16 17:21:16 UTC
BTW, if I copy paste part of this webpage into Xamarin Studio, it inserts fine, but I have to press Ctrl-Z twice to get it removed. But that is maybe another bug, related to edit actions...
Comment 24 Cody Russell 2013-09-27 14:23:28 UTC
Comment 25 Cody Russell 2013-11-15 12:17:43 UTC
*** Bug 16266 has been marked as a duplicate of this bug. ***
Comment 26 Mikayla Hutchinson [MSFT] 2013-11-19 02:13:27 UTC
*** Bug 16330 has been marked as a duplicate of this bug. ***
Comment 27 Mikayla Hutchinson [MSFT] 2013-11-19 02:14:16 UTC
*** Bug 16266 has been marked as a duplicate of this bug. ***
Comment 28 Mikayla Hutchinson [MSFT] 2013-11-20 14:31:52 UTC
*** Bug 7306 has been marked as a duplicate of this bug. ***
Comment 29 Mikayla Hutchinson [MSFT] 2013-11-26 15:11:17 UTC
*** Bug 16464 has been marked as a duplicate of this bug. ***
Comment 30 Gabriël van der Kruijk 2013-12-18 02:33:34 UTC
This issue is still happening on Xamarin Studio 4.2.2 (build 2) on a Windows 7 machine.

Language: Dutch
Lay-out: United States-International
Comment 31 Bernardo 2013-12-18 03:44:23 UTC
I can confirm that too. 
I can't write accents in spanish keyboard in code editor neither in xml editor.

My version is Xamarin Studio 4.2.2 (build 2)
Comment 32 Cody Russell 2013-12-18 09:26:46 UTC
It sounds like you're on the stable channel.  This patch has only been released to beta channel so far.