https://bugs.kde.org/show_bug.cgi?id=406295
--- Comment #3 from Adam Williamson <ad...@happyassassin.net> ---
So I've been beating my head against this all day and not getting *that* far,
but I can at least say the problem is caused by our handling of clicks on the
checkbox in discover/qml/SourcesPage.qml:
onClicked: {
sourcesView.model.setData(idx, checkState,
Qt.CheckStateRole)
checked = Qt.binding(function() { return modelChecked
!== Qt.Unchecked; })
}
this is the bit that makes clicking the checkbox actually do something. What
it's *supposed* to do is tell the source backend to actually enable or disable
the source and then update its record as to whether the checkbox should be
checked or not - this all happens when we call sourcesView.model.setData - and
then reset the 'checked' state to whatever the backend now thinks it should be
(so the checkbox should change state if it did, or stay the same if it didn't).
If you take the onClicked block out entirely, the checkboxes will respond
perfectly to being clicked whichever state they're in. Of course, they won't
*do* anything. If that block is there, clicking them does what it is supposed
to so long as the backend supports it, but the checkbox gets sort of 'stuck' as
described here. Note that a *second* click while it's stuck does not change the
state again.
Interestingly, neither taking the `checked = Qt.binding(function() { return
modelChecked !== Qt.Unchecked; })` line out nor exactly inverting its logic (to
=== instead of !==) changes the observed behaviour *at all*.
The bug is not apparent on flatpak sources because of
https://bugs.kde.org/show_bug.cgi?id=443455 (the flatpak source backend is just
flat out missing the code to enable or disable sources), and it's not apparent
on PackageKit sources because the way that backend works is that it entirely
rebuilds the source list any time the repo configuration changes at all, which
sort of hides the bug.
--
You are receiving this mail because:
You are watching all bug changes.
