| ervin |
Some applications don't want the wait for apply / ok / cancel
and prefer to automatically save the settings when the settings
changes.
This is used in Windows, macOS, Android, iOS, GNOME, and other systems.
This is the first step to make KDE settings instant
| No Linters Available |
| No Unit Test Coverage |
| Buildable 20222 | |
| Build 20240: arc lint + arc unit |
It could make sense to add a test.
Also for an application (system settings or kconfig dialogs) it's already possible to just trigger save when the kcm has changed (we already have signals for this). Why do you think it's needed?
Because not all apps that use KConfigXT use a KCM, and I don't want to make
it necessary to do so. This particular change is done with Kirogi in mind
(that does not uses a KCM, and it's a pure QtQuick / Kirigami app, but uses
KConfigXT)
I'll add the testcase.
Still this is the wrong layer of abstraction for that. KCM would need to adapt to the platform to autosave or not, if you're not using KCM then your own GUI need to adapt to the platform instead. By having this controlled by kconfig_compiler, the application gets no chance to adapt to the platform since it'll always be autosave as soon as you use the setting, whatever the platform.
It needs to be solved higher up in the stack: KCM type of facilities. As you can tell, I'm very much against that change. ;-)
| autotests/kconfig_compiler/test_signal.h.ref | ||
|---|---|---|
| 137 | How about having isSaveNeededChanged(bool)? It could be in KCoreConfigSkeleton. | |
| src/kconfig_compiler/kconfig_compiler.cpp | ||
| 2121 | Seems like this endl belongs outside the loop. | |
| 2125 | If it's in every instance, it should be part of the parent class (KCoreConfigSkeleton) rather than the generated code. | |
| autotests/kconfig_compiler/test_signal.h.ref | ||
|---|---|---|
| 137 | Damn, and I was wondering which better name we could use... it was already there all along since KCoreConfigSkeleton has isSaveNeeded indeed... Thanks Aleix! :-) Note this means the logic will need to be adjusted though since it'll also need being emitted only when the value changes. AFAICT currently it does emit always on property change while only the first change would be necessary... also it won't emit again on load() calls when it's most likely we're rolling back. | |
I agree with the comments, but I'm a bit lost on how to implement that in KCoreConfigSkeleton:
the isSaveNeeded reads the value of the variable and return if it's different from the reference variable. (that I tougth it was a reference *value*, to find out that it's a *variable reference*.
so, if I change my setting via:
Setting::self()->setSomething(5)
the code for this setSomething will not call any KCoreConfigSkeleton code, but will just do a:
GeneratedConfig::setSomething(int value) {
mSomething = value;
}
this is then handled internally on the KCoreSkeletonItem but I don't really understand how.
anyone has a hint on how I can trigger a signal on it?
I'm a bit lost.
Maybe look at KConfigCompilerSignallingItem? But I don't see another way of doing it than a wrapper approach like KConfigCompilerSignallingItem does... but then that's why ManagedConfigModule assumes GenerateProperties=true in the kcfgc, otherwise we'd have hacked the compiler to do the same thing anyway just inconditionnally...
That's why personally I think it's fine to assume people need to opt-in for GenerateProperties if they want the feature, it's closely related after all.
That's why personally I think it's fine to assume people need to opt-in for GenerateProperties if they want the feature, it's closely related after all.
I disagree here.
my application can be a simple QWidget based and have a KConfigXT enabled configuration dialog that I want to trigger a save on any edit.
I don't need properties for that.