Handling of layout/input methods in Unity: what should we do for the LTS?

Tue Nov 12 15:02:11 UTC 2013

Hey everyone,

I'm writing this email to get some input on how we should handle 
keyboard layouts/emails for the LTS.

=== Summary ===

In Ubuntu 13.10 we followed GNOME changes on how keyboard layouts and 
input methods are handle. Some of you probably noticed that things 
didn't go flawlessly there. While some of the issues after been 
addressed through SRUs, and some others are understood/being worked, we 
are still looking at what would be the best option for the LTS.

=== Some details on the changes ===
(feel free to skip if you are not interested in those)

Disclamer: I'm trying to provide a summary based on my understanding of 
the situation, feel free to correct me if some of the things I write are 
wrong (which wouldn't be surprising, I don't claim knowing the topic 
well, I've just been trying to understand the current situation to see 
how we resolve it)

* Before Ubuntu 13.10:

- keyboard layouts and input methods were handled separatly
- gnome-control-center and gnome-settings daemon were handling the 
keyboard layouts only (GUI to configure the layout and the key to cycle 
through them, indicator to change the active layout)
- ibus was handling the input methods (different configuration UI, 
indicator)
- cycling through layout was done through Xorg group cycle (e.g GNOME 
was defining the "change layout" key and telling xorg), the default 
combinaison being alt-shift
- cycling through input method was done through ibus, using a different 
keybinding

* Since Ubuntu 13.10

- GNOME merged both concepts to provide an unified experience [1] 
(trying to clean the old codebase/stack which was hackish and xorg 
specific, improving the user experience as well)
- we have been holding on those changes for several cycles but decided 
to try to deal with that in 13.10, since it was the cycle before the LTS 
and seemed the right time to try
- we followed the Ubuntu design on [2] for the UI
- gnome-settings-daemon/gnome-control-center handle both layouts and 
input methods
- there is only one list of input sources, one indicator, one keybinding 
to cycle
- since the keybinding is changing both ibus and xkb configurations, we 
can't use xorg directly to do the cycle, we need to grab the keys on the 
client side and act from the shell/gnome-settings-daemon (the grabbing 
is creating some of the issues)
- the way the xkb configure is done changed, we used to have all 
configured layouts active (which limited the list to 4 of those), now 
there is only one at time (that creates issues for some clients like 
libreoffice and make keybinding not work anymore in non-latin keymaps [2])

That's basically a summary of the situation

=== Issues in 13.10 ===

We released 13.10 with the new components:
- indicator-keyboard replacing the old gnome-settings-daemon-hacked 
indicator
- gnome-settings-daemon using the GNOME 3.8 upstream code to handle 
input sources
- gnome-control-center having a "custom" version of the configuration UI 
based on our design document

Things seem to be mostly working, from our testing ... it turned out 
they were not working so great as [3] shows.

* Trying to do a summary of the issues we found:

- the control center UI wouldn't take a new keybinding -> that was fixed 
in a SRU

- using modifier only keys didn't work -> that was fixed in a SRU (but 
with side effect)

- some keys are not working (e.g setting "capslock" for layout cycling)

- setting modifier only keys leads to issues where the keys can't be 
used in applications anymore, e.g if "ctrl-shift" is used for input 
switching, you can't use "ctrl-shift-del" in firefox -> that issue 
happen because we still grab the keys from gnome-settings-daemon, GNOME 
resolved the problem by making gnome-shell do the grabbing, we are 
looking at doing the same under Unity

- when "nextgrp:" was defined by xorg the key couldn't be reused, that 
was an upstream GNOME issue and we backported a patch to fix it [4] 
(which basically unset that option on start)

- super-space, which is the new default keybinding to "cycle input 
source" doesn't work well -> there was a conflict with ibus using the 
same binding (that's being changed), super is also used by unity and 
lead to issues where the "keys usage summary" screen gets displayed when 
trying to change layout

- standard keybindings don't work in non-latin keymaps in e.g 
libreoffice (and probably other softwares). See [5] for details, 
basically the way xkb groups are handled now is different and 
libreoffice needs to be "fixed" to look for matching keys in other 
groups (GTK/Qt do that so it works for most applications, not sure what 
out of libreoffice has the issue ... likely things using their own 
toolkit (eclipse seems to have it as well)

=== What do we do for the LTS ===

So basically we are still looking at fixing some of the issues (especial 
gnome-settings-daemon "eating" the modifiers which leads to keybindings 
not working in applications then).

Once those fixes are in we are let with those issues:

- some clients app need to be "fixed" to support multiple xkb groups 
(libreoffice being the most obvious, we likely have other ones)
- there might be still some issues with some keys (e.g using "capslock" 
to cycle)? (things are more difficult from the client side that letting 
xorg handle the layout cycling by itself as it used to do)
- <issues not listed there that might still be happening with the new 
system>

Our options for this cycle are basically:

*  keep pushing forward to try to solve those issues (e.g move the 
keygrabbing to compiz, look at where we stand there).

That should give us a mostly working system, but:
- it means increasing changes before a LTS, which has potential to 
create new issues
- we are not sure that applications are going to be fixed before the 
LTS, and how much of an annoyance that's going to be for our users
- we are spending more efforts on trying to fix things for Unity7/xorg, 
for a problem that is going to go away with Unity8/Mir (things are going 
to work differently under Mir/wayland)

* roll back to what we had until 13.04

The code might be old and not easy to maintain but it seemed to be 
working for most users, some drawbacks:
- it means basically adding back revert patches to 
gnome-settings-daemon/gnome-control-center, that's not really elegant 
but we had those until previous cycle and it was working
- we are back having an interaction with different menus for keyboard 
layouts and input methods ... that doesn't seem an issue for most users 
from the feedback we got (seems most users either use 1 layout and cycle 
through IMs (e.g type english or pinyin on a qwerty keyboard), or use 
different layouts but not IM with those)
- we stop using our new keyboard indicator/get back to an UI which is 
not what our design document recommend

Of course, if we roll back for the LTS, we still plan to address the 
issue properly in Unity8

Sorry for the long email, I hope the details are useful to understand 
the current situation.

If anyone has an opinion on the topic we would welcome your thoughts 
(especially since most of us, in the Desktop Team, have a limited use of 
those options ... which means we might overlook some of the frustrating 
issues in the current limitations).
Does it seem reasonable to try pushing more in that direction, or would 
it make sense to revert and go back to something we know to be working 
for the LTS?

Cheers,
Sebastien Bacher, writing for the Ubuntu Desktop Team

[1] 
https://wiki.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/InputLanguage
[2] https://wiki.ubuntu.com/LanguageAndText
[3] https://launchpad.net/bugs/1218322
[4] 
https://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-3-8&id=86a894e50787405cc2c3503bb82b4bf94d79a705
[5] https://bugs.freedesktop.org/show_bug.cgi?id=55585#c0