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

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.

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)

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.

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).

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

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.

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)

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.