Now that KCModule exposes a defaulted() signal, consume it and keep our
own defaulted state up to date. This is exposed for further consumption
in the GUIs integrating KCModuleProxy.
This depends on: https://phabricator.kde.org/D25069
mart | |
davidedmundson | |
dfaure |
Plasma | |
Frameworks |
Now that KCModule exposes a defaulted() signal, consume it and keep our
own defaulted state up to date. This is exposed for further consumption
in the GUIs integrating KCModuleProxy.
This depends on: https://phabricator.kde.org/D25069
Lint Skipped |
Unit Tests Skipped |
Buildable 18492 | |
Build 18510: arc lint + arc unit |
src/kcmoduleproxy.cpp | ||
---|---|---|
196–197 ↗ | (On Diff #69041) | Why emit changed? Given KCModuleProxy mirrors KCModule API I would have expected a defaulted signal to match? |
src/kcmoduleproxy.cpp | ||
---|---|---|
196–197 ↗ | (On Diff #69041) | Because all the consumers I found surprisingly don't care about the distinction or the value of that bool. Also it would have led to more intrusive changes in said consumers. I admit I was surprised about that. |
Edit: ah, I see why.
KCMMultiDialog and system settings re-evaluate the buttons on receipt of the changed signal
Still seems maybe a bit odd, but it makes sense in context.
I don't disagree, it makes it look odd. I just didn't feel going for the even more intrusive route, I touched quite a few moving pieces already.