I confirmed I had the same problem in Unity and Chromium with the same setup that you are showing, but fixed it with the following workaround.
The existing problem is that even when the menubar correctly shows that you have switched the layout to, say, S1, Unity reacts as if it is using the English layout.
That is, only English output is produced, even though the indicator says S1. Key presses in Unity will only produce the English key, or nothing will appear if no key corresponds to the Serbian combo, or another part of the interface will fire if the combo happens to trigger it. Other applications, however, for example, gedit, will correctly use the Serbian layout shown in the menubar; but Unity still only reacts as if the layout is set to English. In addition, this is not affected by changing the font.
There are 2 issues:
- There is a bug somewhere.
- This answer provides a workaround for the bug.
Please also note that:
This has nothing to do with input methods. This worked with the default input method set to ibus, fcitx, or none.
This is also not related to settings in xkb-options, such as the Compose Key or the 3rd level chooser (referred to as Alternative Characters Key in Keyboard >> Typing.
(You don't have either of these set; this point is just for completeness.)
The key setting is found in System Settings >> TextEntry.
The default setting is Use the same source for all windows. Unfortunately, the default setting seems to always create the problem.
The workaround is to switch this to Allow different sources for each window.
The New windows setting will work with either choice, but use the default choice seems to be less quirky and work correctly more consistently.
You shouldn't need to log out and in, but it doesn't hurt. At this point, entry with the Serbian keyboards works in both Chromium and Unity search. Well, most of the time. I discovered that Unity is still sometimes a little quirky, but this is also easily worked around.
With New windows use the default source, things worked as expected almost all of the time:
That is, you open Unity, the source switches to English, then you use Ctrl+Space to switch the source. Now the source is S1 (latin). Typing [ correctly produces š and keys that depend on a combination also work correctly in Unity. For example, Right-Alt+a produces æ.
The quirk is that sometimes Unity's input source and the input source displayed in the keyboard indicator seem to get out of sync and you get or continue to get the problem as described above.
The work around for this quirk is to cycle through the input sources. Press Ctrl+Space until you get back to the source you want.
This re-syncs the input sources most of the time. A few times I had to cycle through twice. Another time, I had to cycle through the sources, exit out of Unity and restart Unity.
The good news is that once the sources are re-synced they seem to stay correct through the rest of the session.
Better yet, as mentioned above, using the setting new windows use default source seems to prevent the quirk from happening in the first place almost all of the time.
The frequency of this quirk appears to be:
- Under the default setting
Use the same source for all windows: Always. It will never work.
- Under the setting
Allow different sources -- new use current source: Frequent. Cycling through the input sources and sometimes exiting/restarting Unity is frequently needed.
- Under the setting
Allow different sources -- new use default source: Rare. Works as intended most of the time. Cycling through the input sources and sometimes exiting/restarting Unity needed now and then, but not often.
I couldn't find this bug in Launchpad, so you may want to report a new bug against input source switching. (I'm not sure of the exact package to report.) There are similar bugs in Launchpad, but all of the ones I saw were older and were not active.
localeon a console