Autor: anonym Data: A: The Tails public development discussion list Assumpte: Re: [Tails-dev] [review'n'merge:1.1]
bugfix/7065-keyboard-localization
09/05/14 17:36, intrigeri wrote: > Hi,
>
> bugfix/7065-keyboard-localization fixes issue #7065 for me.
> Assigned to the RM (anonym) for review.
>
> The solution I've found to this problem is partly implemented in the
> greeter, and partly in the main Git repo, so it'll require two Git
> merges + an APT merge (or, ideally, a new tails-greeter release
> uploaded to the devel suite).
>
> I have successfully tested an ISO built from this branch with the
> French, French (alternative), Italian, English and Chinese
> keyboard layouts.
Code looks good and it certainly improves the situation. I'll merge the
current state, and upload a new Greeter package in a few minutes. But I
won't close the ticket...
>From the commit message: > Note that we don't set layouts to [chosen one, US] anymore, as I
> could not make it work properly: in this case, regardless of the
> order in which we set it, the US layout wins and is applied by
> default in the session. Anyway, it's easy enough to either directly
> choose US in the greeter (when one wants the GUI in their preferred
> language, and a US keyboard layout), or to add the US layout in the
> GNOME settings (when using both layouts in the same session). So,
> this seems like an acceptable regression to me.
Isn't a US layout pretty much mandatory to have on switch for non-latin
based layouts? E.g. most of the Internet use ASCII URLs, many websites
only accept (a subset of) ASCII for credentials, terminal commands are
in ASCII, etc, etc.
It seems to me like having the US layout on switch is essential for
non-latin layouts. While adding the US layout via GNOME settings is a
workaround, it's incredible inconvenient, and AFAIK we haven't
documented it. Fixing either of these is a blocker for 1.1.
Luckily I think I have a (start for a) solution to get back what we had:
Applying this patch will enable the double layout, with the chosen one
as default. The `sleep` is necessary, so there's something racy here. Of
course, this "sleep fix" is racy too, e.g. sleeping for 10 seconds may
not be enough on slow hardware. The best would be if we could figure out
exactly what it is we need to wait for. Also, note that setting
"layouts" twice like that seems necessary (and it will ensure that the
correct layout is set while we `sleep`).
However, even if I'd prefer a solution without a static sleep, I prefer
shipping this in 1.1 compared to our other options.
