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.
Cmd-C,V,Z,S not working when switched to alternate (not the english one) keyboard input source.
Does the keyboard input in the text editor work ?
I suspect it's something with the command system since the cut/copy/paste actions are bound there.
Yes, input works, but not shortcuts. If i change e.g. copy shortcut to the russian CMD-C, it works only when the russian input source is active. I think english shortcuts should work in any language, mapping keys not chars. Just like it works in any other editor app.
I'm not sure what you're asking for here, and since I'm not familiar with using Russian keyboard layouts I cannot test it. Could you explain in some more detail?
If I understand correctly, you're saying:
* you switch between some Russian layout and some English layout
* Cmd-S works in English, but not Russian.
* If you rebind Cmd-S while in Russia, it works in Russian but not in English.
* You expect the same keypress to perform the shortcut in both layouts.
What's not clear to me:
* Which Russian and English layouts are you using?
* When you do "Cmd-S" in both layouts, are these the same physical keys?
* What is "Cmd-S" in Russian layout? Is it actually a Latin "s" character, or some Cyrillic character?
* How is MonoDevelop's keybinding editor interpreting your inputs?
It's necessary for us to perform keyboard mapping so that the user can actually type the shortcut shown in the menu, instead of having to mentally remap it to an English layout - for example, Cmd-A with the French AZERTY layout.
What you're asking for might be possible if the command system tried to fall back to interpreting the keycode using some English layout if it could not be resolved using the active layout. Not sure what the English layout should be though... US? International?
I'm a little skeptical this is the correct solution as this might cause some surprise if a user accidentally types some keys that don't match a shortcut, but and it triggers a command via the English layout.
Do you know how apps on MacOS/Window usually handle this?
* I'm switching between U.S. and Russian-PC layouts; "Use the same one in all documents" keyboard option set.
* Cmd-S works in English, but not Russian. Exactly. This is the same physical key but very different chars.
* If I rebind Cmd-S while in Russian, it works in Russian but not in English. Yes. Keybinding editor interprets it as a char code while in russian.
* I expect the same keypress to perform the shortcut in both layouts.
I don't remember any application where i could change bindings and have to change layouts to perform binded action.
I've just tried to remap CMD-S to CMD-L in Netbeans and RubyMine:
* They show CMD-L when user remaps, regardless of current layout
* They handle CMD-L, regardless of current layout. Physical english L, no matter it is actually Д in russian.
I'm not sure but think osx/win apps usually map key-codes rather than char-codes. I don't mind french impact on keymaps here but i was REALLY frustrated last year using raw AZERTY without any corresponding QWERTY in Paris :). In Russia we use keyboards where we have both cyrillic and english glyphs on buttons. In every app shortcuts in menu displayed in english, but work in any layout.
We only remap the input, not the bindings. So, to use AZERTY as an example again - we would display Select All as Cmd-A, not Cmd-Q. When you type Cmd-A with the A of AZERTY, it would trigger Select All (Cmd-A), not Quit (Cmd-Q). This means that the menu labels and the actual keyboard are consistent.
Apple's DefaultKeyBinding.dict system appears to be character-based, FWIW. I have no idea how it deals with different layouts.
Anyway, I can think of a few ways to fix this, none ideal:
a) the keybinding system could always use an english layout for key mapping. This would be inconsistent with the actual keyboard in many cases, so quite confusing, e.g. Cmd-A would correspond to the keys labelled Cmd-Q on AZERTY.
b) the keybindings could be remapped from english onto the current layout, and displayed that way. This is difficult to implement, and they might not make sense, e.g. Select All would become cmd-Q in AZERTY.
c) The keybinding system wouldn't change the way it stored or displayed keys. When interpreting input keys, it would try to resolve them to bindings using the active keymap, and if that failed, then it would try again using the english keymap. This might be rather non-obvious, and we'd have to assume that our choice of english layout matched what the user expected.
d) We could special case certain known layouts that are known to be used switched to/from english, and use the english keymap for resolving shortcuts on those layouts. This would mean we could fix specific cases like yours without risking breaking other causes. But it might still have the disadvantages of (a), for numbers, punctuation etc.
I know it might sounds like I'm hung up on AZERTY, but I'm just using it as a simple example. There are many other keyboard layouts that move punctuation around, etc.
Something related - https://trac.gajim.org/ticket/1503 + look at related links there.
*** Bug 625 has been marked as a duplicate of this bug. ***
*** Bug 1441 has been marked as a duplicate of this bug. ***
Moving from MonoDevelop to Xamarin, I sincerely hoped for a fix for this very annoying issue. Seems like both applications bind their hotkeys to English keyboard layout, which is not something you would expect since no other application that I know has this issue.
I would be happy to provide whatever debug information needed to help solve this issue. Judging by the duplicate bug reports, two years have passed, but still no end in sight for what is a major bug affecting all users who have several keyboard layouts (input sources).
See comment 5, I think (c) is the way to go, but I can't find a way to access any keymap other than the default.
*** Bug 17050 has been marked as a duplicate of this bug. ***
Would be great if someone can summarize what is the status of this bug. It's still being reproduced. I would be happy to have any solution that will allow me to press cmd+c/v/q/x at least to be able to copy/paste/quit XS with russian input.
I can confirm that this is a very annoying bug and it is still 100% reproducible after two years.
The worst part is that shortcuts don't work even if you change the layout, YOU HAVE TO CLOSE THE XAMARIN STUDIO, CHANGE LAYOUT AND THEN START IT AGAIN! Any time! Just imagine how much time this consumes!
Why are you ignoring all these developers from outside the US? Is kind of rasism or what?))
Cmon, it should be easy to fix guys! :)
JIC - my OS is Win 8, russian keyboard
As I know, it's a bug of whole gnome. For me no matter with what layout app was started. If first key was pressed not in US layout (even ctrl, shift), shortcuts will be breaked. Monodevelop is most crappy soft, crashes every minute, losing files and references, but price bigger than visual studio. Just buy Parallels Desktop + Windows 8.1 + Visual Studio 2013.
Confirm that bug too, I'm very surprised it lives for so long!
Mac OS X 10.10
Xamarin Studio 5.7.1
That's very strange to have such bug in native MacOS application, I'm not sure, but it seems like such mappings are done on OS level.
All shortcuts like Cmd-A / Cmd-C / Cmd-V / Cmd-Z etc are usually working in every application regardless of current layout, e.g. system receives Cmd-Ф / Cmd-С / Cmd-М / Cmd-Я on QWERTY/ЙЦУКЕН keyboard.
Confirm the bug too,Use the global shortcut 'shift' switch Chinese and English,It only not work in Xamarin Studio ,It work fine in Xcode
Three years people reported about inability of using keyboard shortcuts for editing texts (in IDE!). Sorry, but its a shame.
*** Bug 33645 has been marked as a duplicate of this bug. ***
Any progress on this issue?
IMHO ticket's status could be changed to CONFIRMED or even IN_PROGRESS :)
I have to say this issue is really annoying. Any chances to see fix anytime soon?
*** Bug 57123 has been marked as a duplicate of this bug. ***
Is that bug hasn't fixed yet? This really annoying behaviour. REALLY. Please fix it as soon as it possible. It's too hard to work without cmd+c/cmd+v shortcuts. It doesn't work when we are using Russian keyboard layout.
I was trying to look into this issue again this week but I still don't have any good leads on a solution yet.
First of all, this isn't necessarily a bug on non-Latin keyboards. When I try to reproduce this in a Japanese input source I cannot - it works as expected in Japanese. It also works as expected in Russian when I'm on Linux, so I don't think it's a problem with GTK in general. It fails in Russian or Russian-PC on Mac.
What happens at the toolkit level is when the first key is received (or when the first key is received after the keyboard layout has changed) then we re-build our keymaps and cache the binding data in gtkkeyhash.c. The data for these keymaps ultimately comes from TISGetInputSourceProperty(TISCopyCurrentKeyboardInputSource(), kTISPropertyUnicodeKeyLayoutData). When I trace through that and add debug logging for MOD2 mask (which is our Cmd key) then in English and Japanese I'm seeing key mappings from keycodes 65 ('A') and 97 ('a') over to hardware keycode 0 (which is where the 'a' key is on my US keyboard). When I look at this in Russian or Russian-PC the only keycode I see mapping over to keycode 0 is keycode 100 (which is 'd' and as far as I can tell isn't a key on these keyboard layouts).
I tried to search around and discovered that Qt seems to have the same issue and the bug is still open for them: https://bugreports.qt.io/browse/QTBUG-50865
These APIs that we're using to build the keymaps are Carbon APIs. I'll try to find out if there are some newer APIs that we should be using instead. It could be that Mac's Russian keymaps have changes that the Carbon APIs don't pick up or something.
If there is no newer API that we should be using, and if this really is just limited to Russian keyboard layouts, then perhaps we could have some hard-coded keymaps that get inserted (in addition to what the Carbon APIs return) specifically for Russian keyboard layouts. That seems kind of shady/hacky, but at the moment I have no leads to a better solution.
It is not only with Russian but also for other Cyrillic based layouts (at leas for Ukrainian)
It is also not Mac-specific. I've reproduced this issue recently on Windows 8 and Windows 10 with Russian keyboard input.
BTW, Cody Russell, thank you for looking into this. The problem is still really annoying after all those years. I am working around it by never using a Russian keyboard on the machine where I use Xamarin :)
That ugly behaviour also appears in Visual Studio Community (MacOS).
*** Bug 45001 has been marked as a duplicate of this bug. ***
No good news on that? :)
Oh, yeah sorry. This fix is committed. It should be available in the 15.4 release (15.3 is the current one.. I'm not sure exactly when 15.4 is)
15.4 now is alpha channel, maybe even in beta since recent stable release.
This fix may not be in the channel yet, but if you're on the 15.4 channel then next time it updates the Mono package you should get this fix.
Mono 220.127.116.11 or later is what you want I believe.
> 15.3 is the current one
Unless I'm being very thick, the current one on Windows is 15.1 (monodevelop-windows-d15-1) (both on XS and in VS), which also means we still cannot edit layouts for Android 4 (bug 56272). The Beta channel on Windows is empty, and there is 15.4 in the Alpha channel.
*** Bug 58904 has been marked as a duplicate of this bug. ***
Have verified this bug on “Visual Studio Enterprise 2017 for Mac (Preview) Version 7.2 Preview (7.2 build 547)” and it is found to be fixed.
-Visual Studio Enterprise 2017 for Mac (Preview) Version 7.2 Preview (7.2 build 547)
-Mono 18.104.22.168 (2017-06/ebee14deca1) (64-bit)
-Xamarin.iOS Version: 10.14.0.20
-Xamarin.Android Version: 22.214.171.124
-Xamarin.Mac Version: 126.96.36.199
Detailed Build config: https://gist.github.com/mohakbarokar/befeba9293ee2ff0dda492e2025df481
Marking this Bug as verified/Fixed.