show-desktop (from org.gnome.desktop.wm.keybindings) has the wrong value on first login (Ctrl+Alt+D instead of Ctrl+Super+D)

[Thomi Richards]

The packaging branch that builds compiz into the ~unity-team staging PPA is different to the packaging used for Ubuntu main.

Autopilot runs on machines that have compiz (and other packages from the above PPA) installed directly during the install process, as opposed to upgrading after the install process. We do this using a pre-seed config file as part of the machine provisioning.

When we do this, the config that controls keybindings seems to be very broken. We've observed that:

 * By default, the compiz upstream key combination for show_desktop is Ctrl+Alt+d
 * We apply a distro-patch to turn this into Ctrl+Super+d. This distro patch is present in the packaging branch that is used for the staging PPA as well as Ubuntu main.
 * If you install compiz from main, and then upgrade to the staging PPA, everything seems to work perfectly.
 * If you install from the staging PPA first, the following happens:
  - The python-compizconfig module tells autopilot that the correct keybinding to use is Ctrl+Super+d.
  - When autopilot presses Ctrl+Super+d, or when a user presses those keys on a "real" keyboard, nothing happens.
  - When autopilot (or a real person) pressed Ctrl+Alt+d, compiz runs the "show desktop" action.

What's confusing is that, on the one hand, the compizconfig module reports the correct key combo when we ask for it, but on the other hand, compiz reacts to the wrong key combo.

This bug is causing a HUGE number of failures in our autopilot test suite. It seems to break several key combinations (another one is Ctrl+Super+Up to maximise a window).

If you need any further information to help fix this, please let me know. I can also arrange an SSH login to a system where the issue is.

[Didier Roche-Tolomelli (didrocks)]

So, we had a look at UDS about the issue, what we found is:
- no migration code is involved into this at all, neither gconf -> gsettings, neither special compiz setting migration script
- the guilty process is compiz, running metacity doesn't set this faulty key.

What happens is (in ideal case):
- compiz starts and look at its own keys: it's taking org.compiz.core, show-desktop-key of the current profile path set to '<Control><Super>d'.
- On first boot, it's synchronizing this key to org.gnome.desktop.wm.key for "show-desktop" (no value set by default).

This is working on a normal desktop (quantal only), on a new user and guest session reliably
Thomi is getting ro confirm that it's working with the quantal compiz version on the QA machine
It's working reliably using the staging ppa on the QA machine starting a guest session

It *doesn't* work at all using the staging ppa on the QA machine, creating a new user and log into it.

[Christopher Lee (veebers)]

To reproduce:

Install using the server .iso (choosing no roles, so it is really a base install)
Add staging ppa: sudo apt-add-repository ppa:unity-team/staging
Log into unity session and see that the hide desktop keys are Ctrl-Alt-d (ccsm shows Ctrl-Alt-d as well)
(logging into Guest session the keys are Ctrl-Super-d)

[Daniel van Vugt (vanvugt)]

Incomplete. We've moved packaging to the trunk as of yesterday. This bug is unlikely to be solved, but if it persists please re-open.

[Thomi Richards (thomir-deactivatedaccount)]

This bug still happens. To reproduce easily on a local machine:

1) install ubuntu server, or Ubuntu base image only
2) add unity-team staging PPA
3) install ubuntu-desktop (after an apt-get update obviously).

[Thomi Richards (thomir-deactivatedaccount)]

The compiz version this has been confirmed with is 0.9.8.4+bzr3469pkg0quantal0.

[Daniel van Vugt (vanvugt)]

I don't think this is just to do with staging. I can reproduce it on a stock Ubuntu 12.10 desktop now:
1. Add a new user
2. Switch to that new user
3. Open several windows
4. Press Ctrl+Alt+D
5. Press Ctrl+Super+D
Expected: Windows only hide on Ctrl+Super+D
Observed: Windows only hide on Ctrl+Alt+D

This ONLY happens for the new user until the first reboot. Thereafter it is fixed (Ctrl+Super+D works).

Now, some simple facts:
1. An Ubuntu build of Compiz contains NO mention of Ctrl+Alt+D at all. It is hardcoded to Ctrl+Super+D everywhere in compiz packages for Ubuntu.
2. When the bug occurs, the setting show-desktop in org.gnome.desktop.wm.keybinding is wrong:
    $ gsettings get org.gnome.desktop.wm.keybindings show-desktop
    ['<Primary><Alt>d', '<Primary><Super>d', '<Super>d']
But after a reboot it rights itself:
    $ gsettings get org.gnome.desktop.wm.keybindings show-desktop
    ['<Control><Primary><Super>d']

I don't believe Gnome has a hardcoded default of Ctrl+Alt+D. It looks like the offending setting comes from:
/usr/share/glib-2.0/schemas/10_ubuntu-settings.gschema.override
    show-desktop = ['<Primary><Alt>d','<Primary><Super>d','<Super>d']
provided by package: ubuntu-settings
That's the only place on the system AFAIK that mentions Ctrl+Alt+D at all (Primary = Ctrl).

So a local fix:
1. Edit /usr/share/glib-2.0/schemas/10_ubuntu-settings.gschema.override
2. Change:
    show-desktop = ['<Primary><Alt>d','<Primary><Super>d','<Super>d']
to:
    show-desktop = ['<Primary><Super>d']
3. sudo glib-compile-schemas /usr/share/glib-2.0/schemas
And now new users will not get Ctrl+Alt+D forced upon them. They will get Ctrl+Super+D instead.

A proper fix:
Make the same edit as above in package "ubuntu-settings".

Final notes:
Why is there a race or some kind of delay in the application of gsettings overrides? No idea. I still don't understand overrides. didrocks will have more of a clue.

[Thomi Richards (thomir-deactivatedaccount)]

Comment from Didier via the e-mails:

> Yeah, the default value is in the distro-patch from compiz, but the issue is not there,
> the issue is that compiz is supposed to take the system key (from the gnome
> integration) and reliably copy this key in its configuration each times it boots, which
> it seems to not do on the first boot in this case.
>
> This is what Daniel needs to debug, why this key in compiz itself isn't copied (or ping Sam)

[Daniel van Vugt (vanvugt)]

didrocks is suggesting that the gnome setting should be copied into compiz gsettings instead of proxied, but even if it was, it would be copying the wrong value because of the bug in ubuntu-settings. So that would still have to be fixed first.

It does sound like there might be an inconsistency between the python and C APIs, both returning different values for the same setting. But still, that's irrelevant while ubuntu-settings is forcefully overriding the setting to the wrong value. ubuntu-settings needs fixing first.