Dim timeout gsetting key not set anymore

[Alexandros Frantzis]

The dim-timeout gsettings key is not set anymore when the activity-timeout key changes, so a default value of 45sec is used for dim-timeout regardless of the activity timeout selected by the user in the batter plugin.

The logic to set the dim timeout value is there in battery/SleepValues.xml in the GSettings onChanged handler, but it seems that the onChanged handler is not called when the activity-timeout value changes.

Not sure if this is a problem in the way ubuntu-system-settings uses the GSettings QML item, or if the item implementation itself is broken somehow.

[Jonas G. Drange (jonas-drange)]

I did this:
1. Build and install gsettings-qt from lp:~unity-team/gsettings-qt/bump-changelog
2. Log on onChanged in GSettings in SleepValues.qml
3. Change the sleep value, I get a log and therefore changed event.
4. Reinstall using sudo apt-get install {libgsettings-qt1,qtdeclarative5-gsettings1.0}=0.1+15.04.20150810-0ubuntu1
5. Do step 2 and 3 without any log.

It seems changing a setting using the GSettings binding does not generate the “changed“, but changing it from the command line does.

[Jonas G. Drange (jonas-drange)]

Code which with you can reproduce the issue: http://pastebin.ubuntu.com/12990612/

[Lars Karlitski (larsu)]

We've changed the way the changed signal is dispatched due to Qt bug 32859 (tracked as bug #1460970 here), which leads to these signals not being emitted at all anymore when changing a setting from qml.

I've attached a branch that explicitely emits those signals in that case.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gsettings-qt - 0.1+16.04.20151104-0ubuntu1

---------------
gsettings-qt (0.1+16.04.20151104-0ubuntu1) xenial; urgency=medium

  [ Lars Uebernickel ]
  * qgsettings-qml: explicitly emit changed events (LP: #1503693)

gsettings-qt (0.1+15.04.20150810-0ubuntu1) vivid; urgency=medium

  [ Lukáš Tinkl ]
  * Force handling deferred delete events to avoid memory leaks (LP:
    #1460970)
  * Force handling deferred delete events to avoid memory leaks (LP:
    #1460970)

 -- Sebastien Bacher <email address hidden> Wed, 04 Nov 2015 17:59:13 +0000