Bug 958 - Cannot use keyboard layout switching when within MonoDevelop
Summary: Cannot use keyboard layout switching when within MonoDevelop
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: General ()
Version: 2.6
Hardware: Macintosh Mac OS
: Low normal
Target Milestone: ---
Assignee: Bugzilla
: 11488 ()
Depends on:
Reported: 2011-09-21 07:13 UTC by Chris Hardy [MSFT]
Modified: 2017-07-21 17:35 UTC (History)
6 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 Chris Hardy [MSFT] 2011-09-21 07:13:26 UTC
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.
Comment 2 Alexander Riman 2011-10-26 08:22:28 UTC
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.
Comment 3 Jeffrey Stedfast 2011-11-15 15:47:46 UTC
Is this as simple as replacing the Control+Shift+Space keybinding with some other key combo?
Comment 4 Mikayla Hutchinson [MSFT] 2013-04-01 16:34:10 UTC
*** Bug 11488 has been marked as a duplicate of this bug. ***
Comment 5 Kristian Rietveld (inactive) 2013-04-20 11:58:36 UTC
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.
Comment 6 Ivan 2013-04-20 12:39:09 UTC
@Kristian Rietveld
I'm using Caps Lock hacked to send F19 for layout switching. It doesn't work too. All others software work fine.
Comment 7 Kristian Rietveld (inactive) 2013-04-21 05:00:03 UTC
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?
Comment 8 Amy Burns 2017-07-21 17:35:52 UTC
This is irrelevant in macOS.