Hi,
anonym wrote (12 Nov 2014 00:05:50 GMT) :
> 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.
Makes sense. We're probably racing with gnome-settings-daemon, or its
plugin that manages the keyboard IIRC. And we're also configuring this
at two different levels (dconf on one side, and also our Greeter does
it with xkl, which does impact whatever the GNOME session gets), which
feels just wrong and racy too.
> 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.
Please, let's not do that :)
> The better solution would be to wait for the exact part of
> GNOME to be running and wait for that.
Yes. This or, to the contrary, block the startup of the component
we're racing with until we're done with our part of the setup.
The latter would look a bit nicer to me (pre-configuration vs.
re-configuring on-the-fly after letting the defaults be applied).
Unfortunately, I see no facility in the desktop file spec for
declaring dependencies, so it'll require either ugly hacks, or waiting
until the session is managed by `systemd --user', or finding a way to
configure this *before* we start the rest of the session (that is, ).
> 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.
Indeed. But I think we're just not doing things right here: on
a non-Tails Debian systems, things just work (both at login time and
when reconfiguring them later). I suspect we're simply not using the
preferred interface to configure these bits. OTOH, things are a bit
different on Jessie, and I'd rather avoid spending too much time on
a Wheezy-only solution.
> Billions of people use non-latin keyboard layouts so dropping cc4e759e
> would make their Tails experience much worse than what #7912 does
OK.
> (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).
Looks good enough to me, at least while we're based on Wheezy.
> I have no idea if there's an easy way to detect whether a layout is
> latin-based or not.
No idea either. Would be worth a research ticket.
> And it'd be sad if we'd have to maintain
> a gigantic disjunction of checks against the layout like:
> [ "$XKBLAYOUT" = "jp" ] || [ "$XKBLAYOUT" = "ar" ] || ...
Sure. If we *have to* maintain a hardcoded list (which should ideally
be avoided), then I expect we'll be able to implement this in a nicer
way (grep -qx "$XKBLAYOUT" "$NON_LATIN_LAYOUTS_FILE", or something).
Cheers!
--
intrigeri
