gsettings-qml biderectional list issue
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gsettings-qt |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Excuse the noise, it's my bad, found the status change button for the bug, marked as invalid.
GSettings-qt crashes when qlist (any list value in gsettings), below
Example code:
Binding {target: virtualDesktopS
Binding {target: windowSystem; property: "desktopNames"; value:virtualDe
//windowSystem is another cpp plugin exposing also virtual desktop names
GSettings {id:virtualDesk
}
Scenario A:
You close above application and change the value (as an example the names of the virtual desktops)
somehow externally via windowManager/
from [ "old_desktopname1", "old_desktopname2" ] to [ "new_desktopname1", "new_desktopname2" ]
and restart the application.
//This works
Scenario B:
You close above application and change the value (as an example the names of the virtual desktops)
somehow externally via windowManager/
from [ "old_desktopname1", "old_desktopname2" ] to [ "new_desktopname1", "new_desktopname2", "new_desktopname3" ]
and restart the application.
//The length changed as we added an additional virtual desktop. Now the application just crashes:
//ASSERT failure in QList<T>
//The program has unexpectedly finished.
Workaround:
//change example code to:
property bool startSync
Timer {running:
Binding {target: virtualDesktopS
Binding {target: windowSystem; property: "desktopNames"; value:virtualDe
//windowSystem is another cpp plugin exposing also virtual desktop names
GSettings {id:virtualDesk
}
PS:
Just wondering right now on such a bidirectional binding, if changed while application was not running which one should have precedence (when I set when: it's obvious)? Should GSettings enforce it's settings, or the other side enforce onto GSettings?
But this should be more of a Qt request for a true QML BiDirectionalBi
Changed in gsettings-qt: | |
status: | New → Invalid |
description: | updated |
description: | updated |
description: | updated |
nevermind, the issue is not in gsettings tried with different testcase...