[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Merging a 2nd style (non xml) for KConfigXT?
From:       Tomaz Canabrava <tcanabrava () kde ! org>
Date:       2023-08-30 9:43:27
Message-ID: 94ef8f1e-ebe6-4347-b8e2-f2c6acfa35aa () kde ! org
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]