Hello All,

This is my 2nd attempt on this, but hear me out. I'm using for ~5 years a configuration schema that is really different from KConfigXT XML syntax because I sincerely don't like to hand code XML specially when it's intermixed with C++ within the *same* file, and I feel that all the different possible ways to configure KConfigXT is broken by design. What I'm proposing here is *not* to replace KConfigXT xml schema, I conceive that it's a lost cause on my side. I lost.

What I'm proposing is to add my chema as a *variant* for a smaller, stricter, easier to write and to read, syntax.  it will *not* cover all the cases from KConfigXT (no way to define multiple configuration files, no way to define static vs non static initialization). but it will cover a smaller, to medium configuration complexity.

it already offers some things that KConfigXT Lacks. too. See this small example:

-- file somesmallpreferences.conf

#include <QString>

#include <QFont>

namespace Prefs {

SomePreferences {

    Gui{

        QColor bgColor = QColor(233,233,233);

    }

    User {

        QString name = QStringLiteral("Adamastor");

    }

}

}

-----

This will generate two new files, `somesmallpreferences.h / cpp with the following  classes: SomePreferences, Gui, User.

this generates a property with signal and slots for everything that is considered to be a variable, the constructor of SomePreferences loads everything, the destructor of SomePreferences saves everything.

Things that KConfigXT XML lacks:

* Access to the default value of a setting (KConfigXT allows me to define one, but I can't use it on a if in the codebase, there's no way to query it back)

* Multi paradigm configuration targets (I can deploy for QSettings or KConfig)

* Compartimentalized acessors: bgColor() exists inside of the Gui class, not on SomePreferences, so it's easier to organize.

For a real example, check `invent.kde.org/sdk/codevis` as this is what I'm using there.

I want to merge this on KConfigXT to be able to drop my github based project, and to see if more projects could adopt such a scheme.

Best,

Tomaz

Reply via email to