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

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Sebastien Bacher-4
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


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Sebastien Bacher-4
Le 12/11/2013 16:02, Sebastien Bacher a écrit :
> - 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

Seems I forgot to add a note there ... we already have plans to have a
second version of those packages in the archive for Unity (that's going
to unblock some GNOME remix work), which means the revert would be Unity
specific and not create issues for gnome-shell users

Cheers,
Sebastien Bacher

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Gunnar Hjalmarsson
In reply to this post by Sebastien Bacher-4
On 2013-11-12 16:02, Sebastien Bacher wrote:

<snip>

> * Since Ubuntu 13.10
>
> - GNOME merged both concepts to provide an unified experience [1]

Xubuntu 13.10 integrates keyboard layouts and input methods using IBus.
Probably the GNOME changes haven't much to do with it; maybe IBus 1.5 has.

Anyway, via the IBus indicator I can easily switch between English (US),
Swedish, Chinese, and Korean. Haven't tested shortcuts, though.

Possibly a solution worth exploring for the Unity LTS.

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj


--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

AWASHIRO Ikuya
In reply to this post by Sebastien Bacher-4
Hi Sebastien,

On Tue, 12 Nov 2013 16:02:11 +0100
Sebastien Bacher <[hidden email]> wrote:

> - we stop using our new keyboard indicator/get back to an UI which is
> not what our design document recommend
What does it mean?
 * Someone will write indicator patch for IBus 1.5.
 * We use IBus embedded icon on Unity.
 * We switch back to IBus 1.4.
 * We switch to Fcitx from IBus.
 * or another idea?

Regards,
--
AWASHIRO Ikuya
[hidden email] / [hidden email] / [hidden email]
GPG fingerprint:
1A19 AD66 C53F 2250 3537 1A9D 3A53 2C1D 20AB CC8A

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Sebastien Bacher-4
Hi,

Le 13/11/2013 13:40, AWASHIRO Ikuya a écrit :
> What does it mean?
>   * Someone will write indicator patch for IBus 1.5.
Did we loose our indicator in the ibus 1.4->1.5 transition? We should
add it back in that's the case, yes

>   * We use IBus embedded icon on Unity.
>   * We switch back to IBus 1.4.
Those are not likely to happen no
>   * We switch to Fcitx from IBus.

That's a topic that is going to be discussed at vUDS next week:
http://summit.ubuntu.com/uds-1311/meeting/21984/desktop-1311-default-imf-review/

Cheers,
Sebastien Bacher

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Sebastien Bacher
In reply to this post by Gunnar Hjalmarsson
Le 12/11/2013 17:55, Gunnar Hjalmarsson a écrit :
> Possibly a solution worth exploring for the Unity LTS.

Hey Gunnar,

Thanks for the suggestion. I would prefer avoiding trying a new solution
though, especially during a LTS cycle. We have basically 2 options we
experimented with, it would make sense to just go with one of those...

Cheers,
Sebastien Bacher

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Loïc Minier-17
In reply to this post by Sebastien Bacher-4
On Tue, Nov 12, 2013, Sebastien Bacher wrote:

> *  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)

How will the Mir/Wayland approach look like?  Could we leverage it for
Unity 7?

> * roll back to what we had until 13.04

We can't ship Unity 8 in the desktop for 14.04 due to the dependency on
Mir, so since we picked the "ship known good / stable stack in 14.04
desktop" approach, it would be consistent to pick the good / stable old
way of switching keyboard layouts and handling shortcuts -- unless it's
a lot of work to rollback, in comparison to moving to the new world.

From a risk point of view, the second option seems like the safest one,
but from an efforts point of view this depends on how much work it is to
produce an Unity 8 image with a new keyboard layouts / shortcuts
solution + finding a solution for Ubuntu Desktop.

--
Loïc Minier

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Sebastien Bacher-4
Le 13/11/2013 17:49, Loïc Minier a écrit :
> How will the Mir/Wayland approach look like?  Could we leverage it for
> Unity 7?
I expect the approach in "the new world" to be similar to the recent
work. It should be easier under Mir/Wayland since we are not going to
have to fight with X grabs and xkb limitations there (e.g Mir should be
watching for those events and sending the signal to do the action
associated to the keybinding).

That's a topic that should be discussed with the Mir/Unity8 though ...
do you know if that's on the roadmap for this cycle (handling of
external keyboards and layouts/input methods/keybindings on the desktop)?

> unless it's
> a lot of work to rollback, in comparison to moving to the new world.
Well, we are almost done with the work we have been doing. The issue is
that we are hitting the problems I listed, especially the ones with apps
like libreoffice that require to fix the applications. I expect
applications are not going to be an issue in touch because there is less
"legacy" and the ones newly written or using the standard toolkits
shouldn't have those issues.

Rollback is not that much work in any case.
>  From a risk point of view, the second option seems like the safest one,
> but from an efforts point of view this depends on how much work it is to
> produce an Unity 8 image with a new keyboard layouts / shortcuts
> solution + finding a solution for Ubuntu Desktop.
The solutions are going to be different in both setups (since the input
stack used is not the same), it also depends on the input method
framework we are going to use (there is still the ongoing ibus or fcitx
discussion, with a session at vUDS next week)

Cheers,
Sebastien Bacher

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

Loïc Minier-17
On Wed, Nov 13, 2013, Sebastien Bacher wrote:
> That's a topic that should be discussed with the Mir/Unity8 though
> ... do you know if that's on the roadmap for this cycle (handling of
> external keyboards and layouts/input methods/keybindings on the
> desktop)?

(I don't know whether this is on the roadmap)

--
Loïc Minier

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

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

AWASHIRO Ikuya
In reply to this post by Sebastien Bacher-4
Hi Sebastien,

On Wed, 13 Nov 2013 16:04:14 +0100
Sebastien Bacher <[hidden email]> wrote:

> Did we loose our indicator in the ibus 1.4->1.5 transition? We should
> add it back in that's the case, yes
This is the dropped patch.
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/ibus/saucy/revision/56#debian/patches/05_appindicator.patch

> That's a topic that is going to be discussed at vUDS next week:
> http://summit.ubuntu.com/uds-1311/meeting/21984/desktop-1311-default-imf-review/
I see.
Many Japanese users dislike IBus 1.5. Some Japanese users say it is
a crap. Of course I don't think so.
Such users switch to Fcitx or uim which is default input method
on Debian.
Fcitx(fcitx and fcitx-mozc) is well-worked, well-translated
for Japanese users.
IBus 1.5 is not bad. But I found some issues.
If these problems will be fixed, IBus 1.5 will make better than now
hopefully.

Thanks,
--
AWASHIRO Ikuya
[hidden email] / [hidden email] / [hidden email]
GPG fingerprint:
1A19 AD66 C53F 2250 3537 1A9D 3A53 2C1D 20AB CC8A

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel