Use KConfig (this commit will probably fail here)

[cbcalves]

This build will fail if the process flow does not install KDE framworks.

Change all QSettings to use KConfig

Changed the mainwindow to add missing prefixes, there was no change to use static KConfig from last commit.

[tcanabrava]

can you rebase this to update the CI? master now should be able to compile.

[vrmiguel]

Is there a good reason to use KConfig rather than sticking with QSettings?

On the differences between both, KDE states:

• KConfig allows different backends.
• KConfig provides kiosk.

Which aren't features we seem to be in need of.

If KConfig isn't super necessary then we should probably pass on adding another build and runtime dependency

Edit: @tcanabrava has now told me about the additional security KConfig offers

[tcanabrava]

Just as a complementary explanation, as when I explained to @vrmiguel I was mostly sleeping at 2am.

This is KConfigXt, not KConfig. KConfigXT is a configurator generator that makes impossible for you to use the wrong config, and it also gives the application a coherent way to define configurations. KConfig is the same thing as QSettings with the same possible errors.

The problems that happen with QSettings:

• The settings are defined in runtime, and because of that it's not possible to know what settings an application has
• nor even grepping the code for QSettings work, as we could have this kind of code:

void setSettings(const QString& setting, const QVariant value) {
      QSetting s;
      s.setValue(setting, value);
}

It's also extermely dangerous to use string identification for settings:

void load() {
    QSettings s;
    m_someValue = s.value("context").toInt();
}

void save() {
    QSettings s;
    s.setValue("contest", m_someValue);
}

It's easy to spot the typo in contest / context. but it's not easy to spot the typo with 20 other settings laying around.
Those are the issues that KConfigXT solves.

[liomarhora]

Is this program still being ported to KDE?