Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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.
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 ***
regression from 2.8.x
Works with current newresolven on windows 7.
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)
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.
I'm having problems with double quotes and ~ characters. I'm using Mac OS X 10.8.2 and MonoDevelop 126.96.36.199
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.
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.
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
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
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.
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?
*** Bug 10981 has been marked as a duplicate of this bug. ***
*** Bug 11629 has been marked as a duplicate of this bug. ***
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):
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:
Region and Language
Keyboards and Languages
Keyboards and other input languages
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...
I am perfectly fine only supporting Windows7 and better for international support, I do not care about XP for that scenario.
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.
Alan, could we add this to our patchset?
In comment #11:
> TBH this sounds like a bug in the GTK IME module, this kind of thing should be
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.
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.
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.
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)
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 :-).
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...
*** Bug 16266 has been marked as a duplicate of this bug. ***
*** Bug 16330 has been marked as a duplicate of this bug. ***
*** Bug 7306 has been marked as a duplicate of this bug. ***
*** Bug 16464 has been marked as a duplicate of this bug. ***
This issue is still happening on Xamarin Studio 4.2.2 (build 2) on a Windows 7 machine.
Lay-out: United States-International
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)
It sounds like you're on the stable channel. This patch has only been released to beta channel so far.