On 10/11/14 17:28, intrigeri wrote:
> Hi,
>
> it seems (#7912) that our way to add the US keyboard layout as an
> alternative to the chosen one is racy, and sometimes makes it selected
> as the default layout instead of the chosen one. As indicated on the
> ticket (and one can see much more related back'n'forth and hacks and
> workarounds in the Greeter's Git history), that's an area that has
> historically been fragile and racy.
Let me quote a part of `tails-configure-keyboard` after cc4e759e:
[...]
dconf write /org/gnome/libgnomekbd/keyboard/layouts
"['$XKBLAYOUT\\t$XKBVARIANT']"
if [ "$XKBLAYOUT" != "us" ]; then
# Add 'us' switch. Note that it's important that we set the layout
# on its own above, because otherwise the following will make 'us'
# the default.
dconf write /org/gnome/libgnomekbd/keyboard/layouts
"['$XKBLAYOUT\\t$XKBVARIANT', 'us']"
fi
[...]
The implication of the comment is that the order of the `layouts` list's
elements doesn't matter, but the current internal state of it does, i.e.
whatever is currently set will be kept. Presumably that is only the case
when the appropriate GNOME part (that deals with keyboard layouts) is
running, so my guess it that #7912 triggers when this script runs but
the GNOME part is *not* (yet) running so there never is an internal
state of `layouts` where it's simply the chosen layout.
Adding a static `sleep 10` at the beginning of the script or similar (so
that the responsible GNOME part is ensured to run) could possibly "fix"
the bug. The better solution would be to wait for the exact part of
GNOME to be running and wait for that. And the best would be if GNOME
would do this in a sane manner where the current state isn't relevant
when setting it to a new value.
As I have no technical insight in how GNOME works I'm asking you all,
does the above make sense?
> I'm now tempted to revert to the working state we had in
> feature/wheezy before the alternate US keyboard layout was
> reintroduced (commit cc4e759e).
>
> I'd love to see a proper fix come in, but I'm not confident this will
> happen any time soon, and it seems to be that we should optimize for
> the main use case (as a user, I want the keyboard layout I chose to be
> applied consistently), instead of introducing bugs by trying to cope
> with a less-wide-spread use case (as a user, I want to switch between
> US and $local keyboard layouts) that can still be satisfied (by
> manually adding the US keyboard layout).
>
> Still I'm unsure, as I've no idea how widespread the latter use
> case is. Any idea?
Billions of people use non-latin keyboard layouts so dropping cc4e759e
would make their Tails experience much worse than what #7912 does
(IMHO), so if we're gonna do something like what you suggest, I'm with
sajolida -- we should only add 'us' when a non-latin layout is selected,
and just accept that #7912 happens occasionally for these users (who are
probably (definitely?) well-trained at layout switching any way). I have
no idea if there's an easy way to detect whether a layout is latin-based
or not. And it'd be sad if we'd have to maintain a gigantic disjunction
of checks against the layout like:
[ "$XKBLAYOUT" = "jp" ] || [ "$XKBLAYOUT" = "ar" ] || ...
Cheers!
