Project

General

Profile

Feature #11048

Permanently remove the rest of the keyboard layout

Added by getsby almost 4 years ago. Updated 10 months ago.

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Internationalization
Target version:
-
Start date:
02/03/2016
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Greeter

Description

Hello. I use Tails with only Russian and English keyboard layout.

If I switch the layout I get the Chinese, Vietnamese, and others are not necessary to me. Please give the opportunity to permanently remove unwanted layout.

In previous versions of Tails at the entrance when choosing Russians remained only Russian and English layout, it was very convenient. Thank you.


Related issues

Related to Tails - Bug #10913: Keyboard layout keyboard shortcut has changed Resolved 01/12/2016
Related to Tails - Feature #8294: Research how to detect if a keyboard layout is latin-based or not Confirmed 11/23/2014
Related to Tails - Feature #5464: Revamp Greeter interface Resolved 11/11/2013

History

#1 Updated by sajolida almost 4 years ago

  • Target version deleted (Tails_2.2)

#2 Updated by segfault almost 4 years ago

  • Related to Bug #10913: Keyboard layout keyboard shortcut has changed added

#3 Updated by intrigeri almost 4 years ago

  • Assignee set to getsby
  • QA Check set to Info Needed

Please give the opportunity to permanently remove unwanted layout.

Why?

#4 Updated by segfault over 3 years ago

  • Status changed from New to Confirmed
  • QA Check changed from Info Needed to Dev Needed

Please give the opportunity to permanently remove unwanted layout.

Why?

I guess it is annoying for users who use multiple keyboard layouts to switch between them if there are so many other layouts. At the moment there are three different shortcuts to switch keyboard layouts: alt+shift (probably removed soon, see #11042), both shifts, and the GNOME default super+space. 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.

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

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. If this is correct, I think it would be most convenient for everyone if we could solve #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.

#5 Updated by segfault over 3 years ago

  • Related to Feature #8294: Research how to detect if a keyboard layout is latin-based or not added

#6 Updated by intrigeri over 3 years ago

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 b48956bbcb81b5699fc2fb18944c67941319ecfd for details.

If this is correct, I think it would be most convenient for everyone if we could solve #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 #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 over 3 years ago

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 over 3 years ago

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.

#9 Updated by sajolida over 3 years ago

  • Assignee changed from getsby to segfault

All-right, then segfault: the floor is yours :)

If you're interested in working on this only of course... Otherwise mark it as "Priority: Low" with no assignee.

#10 Updated by segfault over 3 years ago

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 over 3 years ago

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

#12 Updated by sajolida over 3 years ago

  • Assignee changed from segfault to alant
  • QA Check changed from Dev Needed to Info Needed

Let's ask Alan who's the Greeter master! segfault, if you get no answer from him in, let's say, two weeks you should ask someone else, maybe anonym or intrigeri.

#13 Updated by anonym over 3 years ago

  • Assignee changed from alant to segfault
  • QA Check changed from Info Needed to Dev Needed

It seems alant is unavailable.

segfault wrote:

[...] 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?

It sounds a bit ugly, but yes I think this is the way to go. If you can come up with a cheaper (in dev time) solution, that would also be ok. This Greeter will be obsoleted soon so hacks are more acceptable, and the focus should be to get a proper fix in the new Greeter.

Thanks a lot for looking into this, segfault! :)

#14 Updated by u over 2 years ago

Do we agree this only applied to the old greeter?

#15 Updated by intrigeri over 2 years ago

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'.

#16 Updated by u about 1 year ago

  • Affected tool set to Greeter

#17 Updated by u about 1 year ago

  • Related to Feature #12640: Update/rethink next steps for the Greeter revamp added

#18 Updated by u about 1 year ago

  • Related to deleted (Feature #12640: Update/rethink next steps for the Greeter revamp)

#19 Updated by u about 1 year ago

#20 Updated by sajolida 10 months ago

  • Type of work changed from User interface design to Code

Also available in: Atom PDF