Tails

#6 Updated by intrigeri 2016-02-13 04:44:13

> Only the GNOME default one has a variation to switch backwards: super+shift+space. So if users use one of the other shortcuts, they have to skip through all the unwanted layouts.

I’m left unconvinced by this specific argument: we provide a way that works fine wrt. this problem, and ways that don’t. So users who care so much about it can use the way that works fine (and IIRC you’re working on removing the ways that don’t).

> The multiple layouts also annoy me as a user who uses only one keyboard layout, because I press alt+shift or both shifts by accident pretty often (but maybe I’m just very clumsy and this is no problem for other users).

It happens to me as well. I find it annoying too. So far I can live with it.

> Anyway, if I understand the reason for adding these default layouts correctly, it is because they are non-latin based and people who want to use them probably also want to use the english layout to type latin script.

I’m not sure this is the reason:

• For non-Latin layouts we explicitly support with ibus, we add qwerty layout anyway, which addresses the problem you are mentioning here, regardless of what we do for Latin layouts.
• For non-Latin layouts we don’t explicitly support with ibus: no idea what happens off the top of my head, you’ll need to check.
• For other layouts, in Wheezy we didn’t start ibus, so I guess the problem this ticket is about didn’t appear. While on Jessie ibus is started: see commit:b48956bbcb81b5699fc2fb18944c67941319ecfd for details.

> If this is correct, I think it would be most convenient for everyone if we could solve Feature #8294, then remove the current default layouts and only add the english keyboard layout if the layout chosen by the user is a non-latin based.

Almost. If I got it right, what you folks want is to make sure that in config/chroot_local-includes/usr/local/lib/tails-configure-keyboard we enable ibus only for languages that need it. Which indeed depends on Feature #8294. And then this relationship should be expressed in Redmine :)

Disclaimer: I’m confused and maybe I got it totally wrong.

#7 Updated by sajolida 2016-02-13 16:15:04

Without insight on the technicalities here, what looks weird on the
desktop right now is that I end up with some non-Latin input sources
configured by default even if they have no relation with my language
preferences.

You could wonder why Japanese, Chinese, and Vietnamese and not Russian,
Hebrew, or Arabic? I really don’t think that this is an important issue
but it looks clumsy and unjustified.

I tried to remove Chinese (Pinyin) and Japanese (Anthy) from the Region
& Language settings and I was able to add them back in the very same way
as I would add Russian or Hebrew. So I’m sure why they deserve more
attention than any other input source.

I tried to choose Russian keyboard from Tails Greeter and I get Russian,
English, Chinese, Japanese, etc.

#8 Updated by intrigeri 2016-02-15 16:06:25

> You could wonder why Japanese, Chinese, and Vietnamese and not Russian, Hebrew, or Arabic? I really don’t think that this is an important issue but it looks clumsy and unjustified.

Agreed.

#10 Updated by segfault 2016-02-20 10:39:43

> I’m not sure this is the reason:
>
> For non-Latin layouts we explicitly support with ibus, we add qwerty layout anyway, which addresses the problem you are mentioning here, regardless of what we do for Latin layouts.
> For non-Latin layouts we don’t explicitly support with ibus: no idea what happens off the top of my head, you’ll need to check.
> For other layouts, in Wheezy we didn’t start ibus, so I guess the problem this ticket is about didn’t appear. While on Jessie ibus is started: see b48956bbcb81b5699fc2fb18944c67941319ecfd for details.
I see my interpretation of why we add these default keyboard layouts was totally wrong. I now looked through many commits trying to find the one which adds them in the first place and found 47bfd892. But I still don’t understand why we do this instead of letting the user choose the layout he wants in the greeter.

But I found that the current implementation of the greeter does not list these layouts in the keyboard layouts list. I’m trying to figure out how to include them, but I’m not sure how much more time this will cost me / I’m willing to spend on this.

#11 Updated by segfault 2016-02-20 14:31:23

I looked deeper into this and now I think the problem is that the greeter uses libxklavier’s foreach_layout() method to iterate through all layouts known to XKB [1]. The five layouts added by default in Tails are IBus engines and can’t be used via libxklavier / XKB but only via IBus. They are added regardless of the chosen language / layout in [2].

I think the best would be to modify the greeter to use IBus instead of libxklavier / XKB. I managed to get a list of layouts from IBus with this code:

from gi.repository import IBus

bus = IBus.Bus()
engines = bus.list_engines()
layouts = list()
for engine in engines:
    language_name = IBus.get_language_name(engine.get_language())
    engine_name = engine.get_name()
    layouts.append((language_name, engine_name))

layouts.sort()
for layout in layouts:
    print "%s (%s)" % layout

This prints a few layouts, including the five that are only usable via IBus and not via XKB. The list includes some other layouts, that are usable via XKB, but it lacks a lot of those that are included in the greeter and the Region & Language settings. I found that with ibus-setup, one can choose from exactliy this list of layouts.

I don’t know why this list of layouts misses layouts that are included in the greeter and the Region & Language settings. I would prefer using only IBus in the greeter, but the only way I see right now to include all layouts is to use both the existing list from xlibklavier and add the five IBus layouts to this list. Then we have to check if the user chose a XKB or an IBus source and set /org/gnome/desktop/input-sources/sources accordingly, like it is done in [2].

Do you think this is an acceptable solution?

[1] https://git-tails.immerda.ch/greeter/tree/tailsgreeter/language.py#n60
[2] https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/usr/local/lib/tails-configure-keyboard

#14 Updated by Anonymous 2017-06-30 12:53:50

Do we agree this only applied to the old greeter?

#15 Updated by intrigeri 2017-06-30 13:08:10

u wrote:
> Do we agree this only applied to the old greeter?

No, it affects the regular GNOME session, not the Greeter; and we always enable these input methods: ‘pinyin’, ‘anthy’, ‘hangul’, ‘Unikey’, ‘bopomofo’.