Hi,
I've just pushed a merge request for updating the Qt bindings so that
they also understand the keyboard layout business:
https://code.launchpad.net/~christian-w/lightdm/qt-binding-keyboard-layouts/+merge/205356
However, while experimenting with that, I've made a couple of
interesting observations:
1. All greeters I've looked at (Gtk, unmaintained Qt, KDE, Razor-QT,
Unity) don't seem to implement this at all... Ok, the Qt-based greeters
are no surprise. But for Gtk/Unity: I see some references to old bug
reports online if I search for this, but they reference C code, whereas
the Unity greeter is now written completely in Vala. (At least current
bzr trunk.) And ok, Vala is compiled to C, but the Vala code I looked
at contains nothing that I could find that contains anything resembling
keyboard layouts.
Am I missing something here? Currently, it appears to me that nobody is
actually using that code. Nevertheless, I've seen screenshots of the
Unity greeter with a keyboard symbol, is that perhaps an old version?
2. I get a huge list of layouts from the backend, it appears to me that
those are all layouts that are installed on my system. (472 entries) If
I want to use that for writing some kind of layout switcher for a
greeter, I don't see how that could be made usable in a reasonable way.
The only greeter outside of lightdm of which I know that it supports
layouts is gdm3, and that uses the current XkbLayouts X setting to
restrict the available layouts to those, making it much easier for a
system administrator to choose a sane policy of available layouts.
3. The gobject API exposes three properties for keyboard layouts: name,
short description and description. From reading the API, this seems
perfectly reasonable, but looking at the data the contents seems
*really* weird:
- Description is fine, that is something like 'English (US)' or
'Berber (Morocco, Tifinagh extended)'.
- Short description ist empty *most* of the time, but sometimes it
contains a ISO 639-2 (or -3?) language code, but *only* on a
minority of the layouts. (Ok, can probably live with that, but the
name 'short description' is misleading IMHO.)
- Then we come to name, which is the really weird part. For the most
basic layouts, name is simply the X layout code like 'us',
'de',
'at', 'fr', etc. However, if there is a variant (no dead
keys, euro
sign, etc.), then the name field consists of name "\t" variant, so
for example for the Belgian ISO alternative layout, name is equal
to "be\tiso-alternative".
Funny thing is, the API itself works fine, getting the current layout
and then switching to something else is not a problem.
Regards,
Christian
On 7 February 2014 12:49, Christian Seiler <christian at iwakd.de> wrote:> > > 1. All greeters I've looked at (Gtk, unmaintained Qt, KDE, Razor-QT, > Unity) don't seem to implement this at all... Ok, the Qt-based greeters > are no surprise. But for Gtk/Unity: I see some references to old bug > reports online if I search for this, but they reference C code, whereas > the Unity greeter is now written completely in Vala. (At least current > bzr trunk.) And ok, Vala is compiled to C, but the Vala code I looked > at contains nothing that I could find that contains anything resembling > keyboard layouts. > > Am I missing something here? Currently, it appears to me that nobody is > actually using that code. Nevertheless, I've seen screenshots of the > Unity greeter with a keyboard symbol, is that perhaps an old version? >Unity Greeter uses the keyboard indicator which does the keyboard management, so the rest of the greeter GUI doesn't need any knowledge of keyboard layouts. At the time I was adding keyboard support it wasn't clear we would use the same indicator code as the session but in the end we did (as well as using gnome-settings-daemon which manages some keyboard settings).> > 2. I get a huge list of layouts from the backend, it appears to me that > those are all layouts that are installed on my system. (472 entries) If > I want to use that for writing some kind of layout switcher for a > greeter, I don't see how that could be made usable in a reasonable way. > The only greeter outside of lightdm of which I know that it supports > layouts is gdm3, and that uses the current XkbLayouts X setting to > restrict the available layouts to those, making it much easier for a > system administrator to choose a sane policy of available layouts. >I think it depends on how XKB is configured. In my case I only get a few back. I have had a little look at the XKB protocol and it is quite insanely complicated so no surprises it might vary wildly in configuration. However, in the case of GNOME (and by extension Ubuntu) they've moved to using gnome-settings-daemon to switch between keyboard layout / input method combinations. I am not sure if this will become a standard across desktops. My thoughts on where we go from here: - It seems desirable that liblightdm should provide basic support for things that a greeter could need like keyboard support. This functionality will be optional if a greeter wants to use something more complex / appropriate. - We should attempt to transparently support whatever technologies are being used (e.g. Wayland, IBus, etc). - My knowledge of the keyboard system is quite low so anyone who wants to step in and own this part of LightDM is welcome to do so. Thanks, --Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/lightdm/attachments/20140207/870f716f/attachment.html>