https://bugs.kde.org/show_bug.cgi?id=443583
Adam Williamson <ad...@happyassassin.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ad...@happyassassin.net
--- Comment #1 from Adam Williamson <ad...@happyassassin.net> ---
so I've been looking into this, https://bugs.kde.org/show_bug.cgi?id=406295 and
https://bugs.kde.org/show_bug.cgi?id=443455 because they're all kiiinda in the
same area: enabling and disabling software sources, under different backends.
It's interesting that the PackageKit, fwupd and flatpak backends all handle
this very differently, it almost feels like the abstraction model should be at
a higher level so they're forced to do it in more similar ways and can't have
really different behaviours.
In this case, as best as I can tell, the way the PackageKit backend works is
through a lot of signal callbacks between the Discover backend and PackageKit
itself. The Discover PK backend connects to PackageKit's repoListChanged
signal, and any time that signal is triggered, it regenerates its *entire*
internal sources list from scratch (it runs its own resetSources method). When
you click to enable or disable a source in Discover, the PK backend intercepts
what Qt would usually do when you click a checkbox, and just calls PackageKit's
repoEnable function on the relevant repo and then returns; it doesn't even
explicitly redraw the checkbox. Instead it relies on PK then emitting the
repoListChanged and triggering a call to resetSources, which figures everything
out from scratch again. Presumably when it does this, PackageKit sends the
repos in a different order - I guess it sends them in order of last change? -
which is why we see the 'jump to the bottom of the list' behaviour.
So, theoretically we could fix that by having resetSources not just use the
repos in whatever order it gets them from PackageKit, but sort them in some
kind of consistent order (alphabetically?) so that hopefully we'll get the same
ordering every time it's called. Alternatively, we could have it *not* rely on
the repoListChanged -> resetSources trigger, but disconnect that when we're
dealing with a checkbox click and just have it call repoEnable and then change
the checkbox state if it's successful, or log an error and leave the checkbox
state as-is if it's not. This is more or less what the fwupd backend tries to
do...although 406295 is precisely about that not actually *working*, so we'd
have to figure that out too.
--
You are receiving this mail because:
You are watching all bug changes.
