Orientation lock switch doesn't notice gsettings changes

[Charles Kerr]

Changes to the GSettings aren't reflected in the UI unless they're triggered from inside of system settings.

Manual test I tried out on 14.10 r151:

1. launch system settings
2. turn on orientation lock if it's not already on
3. from phablet shell, run "gsettings get com.ubuntu.touch.system rotation-lock" to confirm lock setting reads "true"
4. tap settings' orientation lock switch to disable lock
5. from phablet shell, run "gsettings get com.ubuntu.touch.system rotation-lock" again to confirm lock setting now reads "false"
6. from phablet shell, run "gsettings set com.ubuntu.touch.system rotation-lock true" to enable rotation lock
7. from system sesttings, confirm that the orientation lock switch shows the feature enabled
8. from phablet shell, run "gsettings set com.ubuntu.touch.system rotation-lock false" to disable rotation lock
9. from system sesttings, confirm that the orientation lock switch now shows the feature disabled

Fails on step 6 -- changing the GSettings isn't reflected in the UI.

This also breaks u-s-s if the flag is toggled from the rotation lock indicator (when the rotation lock indicator lands).

[Charles Kerr (charlesk)]

Adding gsettings-qt for another pair of eyes because at first glance the u-s-s code looks alright:

http://bazaar.launchpad.net/~system-settings-touch/ubuntu-system-settings/rtm-14.09/view/head:/plugins/orientation-lock/EntryComponent.qml?start_revid=935

    control: Switch {
        id: control
        objectName: "orientationLockSwitch"
        checked: systemSettings.rotationLock
        onClicked: {
            systemSettings.rotationLock = checked
        }
        GSettings {
            id: systemSettings
            schema.id: "com.ubuntu.touch.system"
        }
    }

[Lars Karlitski (larsu)]

The problem seems to be that the binding (checked: systemSettings.rotationLock) gets destroyed when assigning the value in the click handler. It works if you either explicitly set the value in onChanged of the settings object:

  GSettings {
    id: systemSettings
    schema.id: "com.ubuntu.touch.system"
    onChanged: control.checked = settings.rotationLock
  }

That's a bit ugly, because now the settings object needs to know about all UI elements that depend on it. Alternatively, you can use the Binding element:

  Binding {
    target: control
    property: 'checked'
    value: systemSettings.rotationLock
  }

To be honest, I don't know what the difference between the two ways of binding properties is, but the one with the Binding element works in my test.

(Removing gsettings-qt, as it's not a bug in that)

[Michał Sawicz (saviq)]

We have a general lack of two-way bindings (and for a reason, they're not trivial in async world). Using Binding { } is preferable over assignment in a signal handler, though.

And yeah, the original binding is destroyed because the component assigns a value to its "checked" property, so the binding has nowhere to "live" any more. Having an explicit Binding { } object works around this. Because "checked" changes onClick anyway, you should probably use a Binding the other way, too, instead of assigning to systemSettings.rotationLock.

[Sebastien Bacher (seb128)]

the issue should be already fixed with https://launchpad.net/ubuntu/+source/ubuntu-system-settings/0.3+15.04.20141105.1-0ubuntu1

that's being backported to rtm next