Note: I picked 6.3 as milestone given that it's a low-impact bug (no reports on bugs.kde.org either) and the change introduces a little bit of extra code. If it works out well and people like the change enough, I wouldn't take issue with cherry-picking this to Plasma/6.2 either.
Commit messages
applets/brightness: Always show displays in order of the D-Bus listing
Previously, the applet's brightness sliders were initialized withthe D-Bus listing, but subsequent display additions would alwaysbe added at the end. This is mostly fine, but not always.
After this refactoring, the display model is fully in control ofdetermining its row order without help from the main plugin class.Its rows are the intersection of two collections of source data:
- The list of known display names, a direct mirror of the latestlist of display names on the screen brightness D-Bus interface.
- A hashmap of display data, for displays that were queried.
Not every known display name necessarily has a correspondingrow element, but the order of exposed row elements matches the listof known display names.
Display data is only kept for known display names, unassociated datais removed when names are updated.
This change also makes the plugin more robust againstasync/coroutine code execution ordering bugs.
applets/brightness: Never miss a display on brightness service registration
Since commit c8f60bbf, the display list gets updated when theorg.kde.ScreenBrightness service (provided by PowerDevil) startsor restarts. This exposed a race condition that was already present,but now gets triggered regularly due to tighter timing.
The sequence of events reproducing this bug goes like this:
- The D-Bus service appears,
onServiceRegistered()is invoked. queryAndUpdateDisplays()starts retrieving display properties.- Soon after the D-Bus service came up, it adds another display.
queryAndUpdateDisplays()finishes.- Only at this point we connect to D-Bus display change signals.
In this sequence, the display from (3) is missed and won't show upin the applet until another display change happens at a later point.
Now that the display model is robust against duplicate insertions,we can simply move queryAndUpdateDisplays() from the start ofonServiceRegistered() to the end of the function, at which pointD-Bus signal connections are already set up. This ensures thatno display additions will be missed, even if they happen immediatelyafter service startup.