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.
I can't change current keyboard layout using combination Cmd + Shift + Space and Cmd + Opt + Space.
This is a system key bindings.
Also, when I switch back to Monodevelop from another app where I used
another language, Monodevelop uses that language (and does not use language
that was before switching from MD). This is a main problem.
Any progress on this?
I have a system setting:
Language & Text -> Input Sources -> Input source options -> Allow a different one for each document.
I use English when I work in MD. When I switch to another app that has different input language activated and then switch back to MD, I got that language as a input source. This is wrong. English be in MD in this case.
Is this as simple as replacing the Control+Shift+Space keybinding with some other key combo?
*** Bug 11488 has been marked as a duplicate of this bug. ***
So the default keyboard shortcuts are: cmd-space and ctrl-cmd-space. Interestingly, cmd-space works in GTK+ applications, ctrl-cmd-space does not.
In general, system-wide keyboard shortcuts seem to be handled correctly, also if a GTK+ application is active. We simply need to find out what is swallowing ctrl-cmd-space.
I'm using Caps Lock hacked to send F19 for layout switching. It doesn't work too. All others software work fine.
Some more details: it looks like the "Select the previous input source" shortcut (default cmd-Space) is handled by the system (the event does not arrive at the application) while the "Select next source in Input menu" shortcut (default ctrl-cmd-space) is handled by the application. Because GTK+ handles keyboard events by itself, the shortcut is not properly handled. However, if the event is passed to [NSApp sendEvent:], then the shortcut is handled correctly.
Secondly, it looks like local application shortcuts get precedence over only the "Select next source in Input menu" shortcut, since the other shortcuts are handled by the system.
At the GDK level we need to decide whether to handle a keyboard event as usual or to pass it to [NSApp sendEvent]. We could for example extract the input source keybinding from the symbolic hot key list (there is Carbon API for this) and when the event matches they keybinding call [NSApp sendEvent]. The behavior will differ from Cocoa though, since local application keybindings are generally handled at the GTK+ level, so checking local keybindings from GDK would give us a nasty layering violation.
The other problem addressed in this bug is that the selected input source does not stick. I *think* this is also handled in the application locally and that the GDK code does not hit the Cocoa code that takes care of this. It looks like that in Cocoa applications, the input source only switches back once you hit a text input control. We would need to investigate what Cocoa applications do in order to switch the input source to the one that was selected previously and how this can be performed by GDK/GTK+ some how. For MonoDevelop it would probably be good enough to switch back to the correct input source when the application gets focus (instead of when an input control is selected).
All in all: not a trivial bug ;)
Mitch: do you happen to have any thoughts on this?
This is irrelevant in macOS.