KCModuleQml: Ensure defaulted is emitted with the current configModule->representsDefaults on load
ClosedPublic

Authored by meven on Dec 18 2019, 3:00 PM.

Details

Summary

ConfigModule are instantiated before KCModuleQml in KCModuleLoader.
ConfigModule can sometimes change their representsDefault before KCModuleQml is instantiated.
Furthermore KCModuleProxyPrivate::loadModule that wires the connection between defaulted signal and the restore button state update is set up after KCModuleQml constructor.
This causes KCModuleQml whose ConfigModule setup their representsDefaults before they are loaded, to have their restore default alwaas enabled regardless of their ConfigModule representsDefaults value.

Test Plan

NightColor KCM with D26049

After:
On load with default settings saved, the "restore default" button is disabled.

Before:
On load "restore default" button is always enabled.

Diff Detail

Repository
R295 KCMUtils
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
meven created this revision.Dec 18 2019, 3:00 PM
Restricted Application added a project: Frameworks. · View Herald TranscriptDec 18 2019, 3:00 PM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
meven requested review of this revision.Dec 18 2019, 3:00 PM
meven added a comment.Dec 19 2019, 8:14 AM

We may want an alternative approach to fix this.
But the end result we want is : ConfigModule should be able to update their representsDefault anytime without having to worry about the restore default button state.
Currently it mostly works except when ConfigModule change its representsDefault state before their KCMModule is instanciated, in which case the first representDefaultChanged event are not relayed.

ervin accepted this revision.Dec 23 2019, 12:29 PM
This revision is now accepted and ready to land.Dec 23 2019, 12:29 PM
This revision was automatically updated to reflect the committed changes.