No way to add other keymap than english on Live CD

[Jean-Baptiste Lallement]

TEST CASE:
1. Boot a live cd
2. Select "Try Ubuntu" and start the live session
3. Click on the Keyboard indicator
  -> Verify that there is no French, Spanish or German keymap on the list (nothing else than US keymaps actually)
4. At the bottom of the list click on "Keyboard Preferences".
  -> It opens the "Region and Language" configuration panel
5. Click on the "Layout" tab to add a new layout

Result:
The list only contains english/us layouts
The "+" button below the list is disabled and no new layout can be added

WORKAROUND
 * On the "Layouts" tab click on "Reset to defaults"
 * All the existing layouts are removed and the "+" button is enabled, the user can then add a new layout.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: gnome-control-center 1:3.0.2-1ubuntu4
ProcVersionSignature: Ubuntu 3.0-1.2-generic 3.0.0-rc3
Uname: Linux 3.0-1-generic x86_64
Architecture: amd64
Date: Wed Jun 22 08:29:28 2011
LiveMediaBuild: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64 (20110621)
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-control-center
UpgradeStatus: No upgrade log present (probably fresh install)

[Martin Pitt (pitti)]

Assigning to Rodrigo, as he's currently working on that part of control-center.

[Benjamin Kerensa (bkerensa)]

Just verified this to be accurate as reported will update for Rodrigo to review.

[Sebastien Bacher (seb128)]

Do you know if there is any error printed on the command line if you run gnome-control-center there? does it work fine on the installed system after a new install? I'm wondering if some depends could be missing there

[Sebastien Bacher (seb128)]

could you try if installing accoutsservice fixes your issue?

[Jean-Baptiste Lallement (jibel)]

Here is the warning displayed without accountsservice installed:
region-cc-panel-WARNING **: Failed to list existing users: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files

This warning is removed once accountsservice is installed but the user is still unable to add a new keyboard layout.

---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

[Sebastien Bacher (seb128)]

the bug is a bit weird, what locale do you select on boot? there should be no keyboard indicator on a live session since there is only one keyboard layout by default. trying on an alpha2 image the region capplet lists layouts as it should, is that still an issue?

[Jean-Baptiste Lallement (jibel)]

I don't change or touch anything on boot. as described in the test case. The only thing I do after booting from the CD is to click on 'Try Ubuntu' at the first ubiquity screen.

Once on the Live Session, there is a keyboard indicator with english layouts which are the same in the 'Region and Language/Layouts' list, but this list is immutable and I cannot add a layout that better suit my keyboard.

Tested and reproduced with today's iso.

[Jean-Baptiste Lallement (jibel)]

Some art to illustrate the problem.

[Sebastien Bacher (seb128)]

we discussed it a bit on IRC and that's rather an ubiquity issue, that's ubiquity-dm which picks the keymap set

[Evan (ev)]

From IRC:
seb128: gnome bug #640774
[17:46] ubottu: Gnome bug 640774 in Region & Language "For some reason I can't add more than 4 layouts" [Normal,New] http://bugzilla.gnome.org/show_bug.cgi?id=640774
[17:46] seb128: ev, no, "x11 design limitation"
[17:46] asac joined the chat room.
[17:46] seb128: ev, will be fixed the day we move to !x11 I guess
[17:46] ev: x11's entire design is a limitation
[17:46] seb128: right
[17:46] seb128: well in that case the limitation is coming from x11
[17:47] ev: right
[17:47] seb128: I'm not sure what's the best way forward now for that bug though
[17:47] seb128: is that wanted that picking english gets you all of existant english layout variants as configured?
[17:48] seb128: could we just pick one and assume users who want other ones can add them using the control center?
[17:48] fishor_ joined the chat room.
[17:49] ev: seb128: mpt suggested picking the top X layouts for that language
[17:49] ev: we'd have to build that data into ubiquity/casper
[17:49] ev: problem is, I'm not sure where we get that data
[17:49] ev: because, alas, we don't measure these things yet
[17:49] cjwatson: shouldn't we undo all the work that ubiquity does if you go through to the live session?
[17:49] cjwatson: it should be as if you never went through ubiquity-m
[17:49] cjwatson: *ubiquity-dm
[17:50] ev: bug 810003 for consistency between ubiquity and casper on this
[17:50] ubottu: Launchpad bug 810003 in casper (Ubuntu) "breaking into just the live CD, skipping ubiquity, should add keyboard layouts relevant to the language selection" [Undecided,New] https://launchpad.net/bugs/810003
[17:50] cjwatson: you could pick the top one layout for that language, that being the information that's already built into console-setup
[17:51] cjwatson: for the time being
[17:51] ev: hmm
[17:52] cjwatson: if we can't do the other thing without breaking stuff
[17:52] fishor joined the chat room.
[17:53] seb128: ev, cjwatson: I reassign bug #800561 to ubiquity, is that ok with you? there is not a lot we can do from the ui side with the x11 limitation
[17:53] ubottu: Launchpad bug 800561 in ubiquity (Ubuntu Oneiric) "No way to add other keymap than english on Live CD" [High,Triaged] https://launchpad.net/bugs/800561
[17:53] seb128: it's also not really practical to have an indicator keymap list going over the screen

[Sebastien Bacher (seb128)]

the issue there is that the active layouts list set by ubiquity hits https://bugzilla.gnome.org/show_bug.cgi?id=646269 and an xorg limitation, the current list is also not really practical from an ui perspective, we should probably default to one keymap and let the user add extra ones from the control center if needed

[Fabio Marconi (fabiomarconi)]

from splash it start regularry in italian

[Evan (ev)]

Moving this to P, as the keyboard indicator work has been disabled while we wait for python xklavier bindings that work. See bug 829186 for details.

[Colin Watson (cjwatson)]

Status update: as of today, as far as I can tell, there are still no GI-friendly xklavier bindings, so Foundations can't move forward with this bug.

[Martin Pitt (pitti)]

Adding an xklavier task to add GI bindings.

[Martin Pitt (pitti)]

There are static xklavier bindings for Python, but as it uses gobject, you can't use it in Python projects which use GI modules such as Gtk or Gobject. Thus it would be nice if xklavier would be introspectable.

I have worked on a set of patches for this and got it almost working (the train ride was half an hour too short :) ). I'm filing this for now to avoid duplicate work by other people. I expect to have it fully working within the next days.

[Sergey V. Udaltsov (svu)]

There is one problem here. I would not want libxklavier to become too dependent on G* stack. It already depends on glib/gobject (that was a hard move to make - and it caused some tension when KDE used libxklavier). Introducing introspection would make libxklaver even more G-ish.

So, here is the question - would it be possible to make introspection optional, so people would be able to build libxklavier without it?

[Martin Pitt (pitti)]

Created attachment 55295
[1/6] Build introspection typelib

Hah, turned out that there was only a tiny bit missing, it's working quite nicely now.

This patch adds the necessary autoconf magic to build a .gir/.typelib, as per https://live.gnome.org/GObjectIntrospection/AutotoolsIntegration

The library needs some annotation fixes and API extensions to make this actually work, though. I'll send these in separate patches, to make it easier to review the individual ones.

[Martin Pitt (pitti)]

(In reply to comment #1)
> So, here is the question - would it be possible to make introspection optional,
> so people would be able to build libxklavier without it?

Yes, GI support is optional. configure detects whether gobject-introspection is available, and if not, just skips it. You can also explicitly disable it with --disable-introspection.

[Martin Pitt (pitti)]

Created attachment 55296
[2/6] Add GI annotations

This just fixes missing annotations, pretty straightforward. This is also relevant for the gtk-doc documentation.

[Martin Pitt (pitti)]

Created attachment 55297
[3/6] Add xkl_config_item_new_with_data() constructor

This and the next two patches add some API to provide methods for record member access, which can't be done through GI (at least not right now).

These might be debatable, I'm happy to discuss these with you. But I tried pretty hard to do without these, I'm fairly convinced that we need them.

The git log descriptions should have all the necessary details.

[Martin Pitt (pitti)]

Created attachment 55298
[4/6] Add Xkl prefix to callback types

[Martin Pitt (pitti)]

Created attachment 55299
[5/6] Add setters for XklConfigRec string arrays

[Martin Pitt (pitti)]

Created attachment 55300
[6/6] Add Python test script for GI binding

And finally, this adds a tests/test_gi.py which demonstrates reading various objects (Engine, ConfigItem, ConfigRec, ConfigRegistry), appends a new layout, and removes it again:

$ LD_LIBRARY_PATH=libxklavier/.libs/ tests/test_gi.py == Engine ==
indicator names: ['Caps Lock', 'Num Lock', 'Scroll Lock', 'Compose', 'Kana', 'Sleep', 'Suspend', 'Mute', 'Misc', 'Mail', 'Charging', 'Shift Lock', 'Group 2', 'Mouse Keys', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '']
group names: ['English (US)', 'German (eliminate dead keys)']
default layout: German (eliminate dead keys)
features: 2F

== Available Layouts ==
[us] English (US), [ad] Catalan, [af] Afghani, [ara] Arabic, [al] Albanian, [am] Armenian, [at] German (Austria), [az] Azerbaijani, [by] Belarusian, [be] Belgian, [bd] Bengali, [in] Indian, [ba] Bosnian, [br] Portuguese (Brazil), [bg] Bulgarian, [ma] Arabic (Morocco), [cm] English (Cameroon), [mm] Burmese, [ca] French (Canada), [cd] French (Democratic Republic of the Congo), [cn] Chinese, [hr] Croatian, [cz] Czech, [dk] Danish, [nl] Dutch, [bt] Dzongkha, [ee] Estonian, [ir] Persian, [iq] Iraqi, [fo] Faroese, [fi] Finnish, [fr] French, [gh] English (Ghana), [gn] French (Guinea), [ge] Georgian, [de] German, [gr] Greek, [hu] Hungarian, [is] Icelandic, [il] Hebrew, [it] Italian, [jp] Japanese, [kg] Kyrgyz, [kh] Khmer (Cambodia), [kz] Kazakh, [la] Lao, [latam] Spanish (Latin American), [lt] Lithuanian, [lv] Latvian, [mao] Maori, [me] Montenegrin, [mk] Macedonian, [mt] Maltese, [mn] Mongolian, [no] Norwegian, [pl] Polish, [pt] Portuguese, [ro] Romanian, [ru] Russian, [rs] Serbian, [si] Slovenian, [sk] Slovak, [es] Spanish, [se] Swedish, [ch] German (Switzerland), [sy] Arabic (Syria), [tj] Tajik, [lk] Sinhala, [th] Thai, [tr] Turkish, [tw] Taiwanese, [ua] Ukrainian, [gb] English (UK), [uz] Uzbek, [vn] Vietnamese, [kr] Korean, [nec_vndr/jp] Japanese (PC-98xx Series), [ie] Irish, [pk] Urdu (Pakistan), [mv] Dhivehi, [za] English (South Africa), [epo] Esperanto, [np] Nepali, [ng] English (Nigeria), [et] Amharic, [sn] Wolof, [brai] Braille, [tm] Turkmen, [ml] Bambara, [tz] Swahili (Tanzania), [ke] Swahili (Kenya), [bw] Tswana, [ph] Filipino,

== ConfigRec ==
Curent configuration:
  Model: pc105
  Layouts: ['us', 'de']
  Variants: ['', 'nodeadkeys']
  Options: ['terminate:ctrl_alt_bksp', 'grp:shifts_toggle']
Adding Danish layout...
Curent configuration:
  Model: pc105
  Layouts: ['us', 'de', 'dk']
  Variants: ['', 'nodeadkeys', '']
  Options: ['terminate:ctrl_alt_bksp', 'grp:shifts_toggle']
Removing Danish layout...
Curent configuration:
  Model: pc105
  Layouts: ['us', 'de']
  Variants: ['', 'nodeadkeys']
  Options: ['terminate:ctrl_alt_bksp', 'grp:shifts_toggle']

[Martin Pitt (pitti)]

Thanks to an uninterrupted 8 hour train ride to Budapest I have a working GI binding of libxklavier now. I'll discuss the patches with upstream now (see upstream bug).

[Martin Pitt (pitti)]

Note that there are still a bunch of warnings from g-ir-scanner about constants without an XKL_* prefix, but I think they are relatively uninteresting to use from bindings.

There are still a few unintrospectable symbols which are harder to fix:

   xklavier.h:97: Warning: Xkl: xkl_set_log_appender: argument fun: Missing (scope) annotation for callback without GDestroyNotify (valid: call, async)

The actual scope of that argument would be "(forever)", or "until you call that function again", but that doesn't exist right now. A clean solution would be to provide a GDestroyNotify, but that would change API. I don't need that part of the API myself, so I'm not particularly interested in it, but if you are, I can work on this, too (perhaps with skipping this one and adding a new function with a GDestroyNotify).

  xkl_engine.h:329: Warning: Xkl: xkl_engine_get_current_state: return value: Invalid non-constant return of bare structure or union; register as boxed type or (skip)

Error message speaks for itself. Interpreters need to know how to copy/create/free objects, which you can't reliably do with bare structs.

  default_log_appender() (because GI cannot support varargs)

But as the test script shows, the majority of the API can be used, so I think it's "good enough" for now.

[Sergey V. Udaltsov (svu)]

Ok, some comments:
1. You did not change VERSION_INFO in configure.ac. I guess it was just overlooked, right? The API is changed, even though in the compatible way.
2. The xkl_config_item_new_with_data - I do not have strong objection, but why are just plain setters/getters not sufficient?
3. Why is that in Makefile.am?
-xklavier_headers = xklavier.h xkl_config_registry.h xkl_engine.h \
- xkl_config_rec.h xkl_config_item.h xkl_engine_marshal.h
+xklavier_headers = xkl_engine.h xkl_config_item.h xkl_config_registry.h \
+ xkl_config_rec.h xkl_engine_marshal.h xklavier.h
4. set_log_appender is mostly for debugging, so for now let's ignore it
5. I will check around get_current_state. Perhaps making it const would be affordable...

[Martin Pitt (pitti)]

(In reply to comment #10)
> Ok, some comments:
> 1. You did not change VERSION_INFO in configure.ac. I guess it was just
> overlooked, right? The API is changed, even though in the compatible way.

Right, sorry, I overlooked it. I should be bumped for the patches 2 to 5.

> 2. The xkl_config_item_new_with_data - I do not have strong objection, but why
> are just plain setters/getters not sufficient?

They would be sufficient. If you prefer individual setters, I can change the patches accordingly.

> 3. Why is that in Makefile.am?
> -xklavier_headers = xklavier.h xkl_config_registry.h xkl_engine.h \
> - xkl_config_rec.h xkl_config_item.h xkl_engine_marshal.h
> +xklavier_headers = xkl_engine.h xkl_config_item.h xkl_config_registry.h \
> + xkl_config_rec.h xkl_engine_marshal.h xklavier.h

With the original order, g-ir-scanner failed on some unknown symbols. It seems to have some left-to-right ordering. That's not very scientific, I know, I'm not a guru for the g-i implementation.

> 4. set_log_appender is mostly for debugging, so for now let's ignore it

Agreed.

> 5. I will check around get_current_state. Perhaps making it const would be
> affordable...

I'm not sure that const will help, as even with const the interpreter might still need to copy the value. Boxing the struct (i. e. providing a proper constructor and _copy() method) should help. Again, I wasn't terribly concerned about this particular method; once you are happy with the current patches and they can land, we can do the finishing touches.

[Sergey V. Udaltsov (svu)]

> Right, sorry, I overlooked it. I should be bumped for the patches 2 to 5.
Would you update the patches?

> They would be sufficient. If you prefer individual setters, I can change the
> patches accordingly.
Let's do it with setters/getters, for flexibility sake.

> With the original order, g-ir-scanner failed on some unknown symbols. It seems
> to have some left-to-right ordering. That's not very scientific, I know, I'm
> not a guru for the g-i implementation.
Ok, let's forget about scientific approach here:)

> I'm not sure that const will help, as even with const the interpreter might
> still need to copy the value. Boxing the struct (i. e. providing a proper
> constructor and _copy() method) should help. Again, I wasn't terribly concerned
> about this particular method; once you are happy with the current patches and
> they can land, we can do the finishing touches.
Agreed.

[Martin Pitt (pitti)]

Created attachment 55308
[3/6] Add XklConfigItem setters

This is now using setters instead of the new constructor. It's also more consistent with patch 5, and indeed more future proof.

This also bumps VERSION_INFO. (No need to do it again for the other two patches, assuming that all these patches go in at the same time without a release in between).

[Martin Pitt (pitti)]

Created attachment 55309
[6/6] Add Python test script for GI binding

This updates the test script to use the setter instead of the new_with_data constructor.

[Martin Pitt (pitti)]

Are you generally happy about these now? If so, I can start working on e. g. the boxing for making get_current_state() introspectable, but I would not want to waste work on this if there's still something you'd like to see fixed in the basics.

Thanks in advance!

[Sergey V. Udaltsov (svu)]

Thanks, that is all now pushed. The only thing is that version info is changed to 18:0:2. I guess your change was not really correct.

[Martin Pitt (pitti)]

Thanks for pushing!

I have a question about the VERSION_INFO bump: As far as I know I did not break any existing API. If I did, I'd like to rectify this, I didn't mean to. That's why I only bumped the revision (as this adds some new API) and age (as it's backwards compatible), but not current (as the new library will work fine with programs linked to .so.17). So what broke the ABI in my patches that required this bump?

Thanks, Martin

[Martin Pitt (pitti)]

Oh, _if_ you need to bump "current", age needs to be reset to 0, as in this case the library is not backwards compatible to any previous ABI.

Martin

[Martin Pitt (pitti)]

Created attachment 55408
Mark unintrospectable methods as (skip)

I have two more patches to provide some fine tuning.

This one just marks unintrospectable methods as (skip) explicitly.

[Martin Pitt (pitti)]

Created attachment 55409
Make xkl_engine_get_current_state() introspectable

This boxes XklState and fixes the return transfer annotation. With this, xkl_engine_get_current_state() is now also introspectable.

Thanks for considering!

[Sergey V. Udaltsov (svu)]

Good! Pushed through!

Thanks (and for blogging as well:)

[Martin Pitt (pitti)]

Thanks! Can you please fix VERSION_INFO in trunk, too? (See comment 17). I. e. either revert back to 17, or if we need a SONAME bump, drop age to 0?

Thanks!

[Sergey V. Udaltsov (svu)]

Look at the new .so name. It is now 16.2.0. It was 16.1.0. Exactly because you did not break the ABI, you only extended it. The crazy thing is that VERSION_INFO does not directly match the so number.

[Martin Pitt (pitti)]

Ah, indeed. I keep getting dazzled by VERSION_INFO, sorry. Thanks for pointing it out and fixing!

Do you plan to do a new release with this soon? Otherwise I'll just add the patches to our packages.

[Martin Pitt (pitti)]

I am sorry, seems I missed one thing: When the development files of libxklavier are not installed in the system, build fails with

  GISCAN Xkl-1.0.gir
In file included from <stdin>:6:0:
/home/martin/upstream/libxklavier/libxklavier/xkl_config_registry.h:24:36: fatal error: libxklavier/xkl_engine.h: No such file or directory

It should use the local include, not the system one.

[Martin Pitt (pitti)]

Created attachment 55638
Use local include files for building GIR

This fixes the build by preferring includes from the local tree.

Thanks and sorry for the oversight!

[Martin Pitt (pitti)]

Backported patch to current version, committed and uploaded to Debian. Will sync once it's through Debian's binNEW.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libxklavier - 5.1-3

---------------
libxklavier (5.1-3) unstable; urgency=low

  [ Josselin Mouette ]
  * Update repository URL.

  [ Martin Pitt ]
  * Add gobject-introspection support: (LP: #800561)
    - Add 00git_introspection.patch: Already accepted upstream, backported
      to 5.1.
    - debian/control.in: Add gir1.2-xkl-1.0 binary package and GI build
      dependencies. Also add dh-autoreconf build dependency.
    - debian/rules: Use dh-autoreconf cdbs module.
    - debian/rules: Bump shlibs to this version, as the patch adds a few new
      methods and the library bumped minor version.
    - Add debian/gir1.2-xkl-1.0.install: Install typelib.
    - debian/libxklavier-dev.install: Install .gir.

 -- Martin Pitt <email address hidden> Mon, 16 Jan 2012 16:18:44 +0100

[Stéphane Graber (stgraber)]

bug 950087 is currently blocking the fix for this bug that's been uploaded to ubiquity trunk this morning

[Stéphane Graber (stgraber)]

Ok, ported the indicator to Xkl and to gsettings, so the indicator should show up again in ubiquity-dm.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubiquity - 2.9.27

---------------
ubiquity (2.9.27) precise; urgency=low

  * Port keyboard indicator from xklavier to Xkl and from gconf to gsettings.
    Update the test accordingly. (LP: #950087, LP: #800561)
  * Add bin/ubiquity-bluetooth-agent, a bluetooth agent allowing any HID
    bluetooth device for 5 minutes, then spawning bluetooth-applet if
    available, otherwise simply dies.
  * Start bluetooth-applet from ubiquity-dm (LP: #644198)
  * Copy /var/lib/bluetooth to /target/var/lib/bluetooth to keep the list
    of trusted devices on the target system. (LP: #644198)
  * Update PO template and translations for new bluetooth string.
  * Automatic update of included source packages: netcfg 1.68ubuntu14,
    partman-auto 93ubuntu20, partman-auto-loop 0ubuntu21.
 -- Stephane Graber <email address hidden> Fri, 09 Mar 2012 12:11:19 -0500