ConfigGroup QML bindings

Sebastian Kügler sebas at kde.org
Tue Dec 20 12:30:33 UTC 2011


So our new settings app has some basic support for reading and writing config 
files, without having to write C++ code. I'm not overly happy with how the API 
looks like, so I'd like to find possible improvements before te tell people to 
write their own config modules against it.

Here's a small exampple that shows the basic usage:

First, instantiating a config object:

    ActiveSettings.ConfigModel {
        id: browserConfig
        file: "active-webbrowserrc"
        group: "webbrowser"
    }

You'd instantiate such an object for every group/file you want access to.

Then, reading and writing:

PlasmaComponents.TextField {
    id: startPageText
    text: "http://plasma-active.org"
    Keys.onReturnPressed: {
        browserConfig.writeEntry("startPage", startPageText.text);
    }
    Component.onCompleted: {
        text = browserConfig.readEntry("startPage");
    }
}

PlasmaComponents.Button {
    id: saveStartPage
    iconSource: "dialog-ok-apply"
    onClicked: browserConfig.writeEntry("startPage", startPageText.text);
}

As you can see, we're not using properties and their notifications, but have 
to resort to procedural reading and writing. It doesn't seem possible to 
dynamically create properties from config entries, so something like

TextField { text: browserConfig.startPage }

doesn't work at this point (while I think the API looks more elegant.

As to writing, I think that's even a bit more complicated, as we'd have to 
assign a default value, a trigger to write the config, usually spread over 
more than one object. (TextField and Button in the above example.)
Note that the ConfigModel object doesn't expose sync() to the QML API, right 
now it automatically compresses syncs and delays them for 5 seconds. (No 
explicit "save config now", as we decided to go for "instant apply", instead 
of "OK" and "Apply" buttons.

As to synching of configurations (pretty important, as for example the active-
settings app  is another process than the webbrowser, right now, the browser 
watches its config files using KDirWatch, and reloads the config if that file 
changes. Works quite well, lacks a bit of elegance, easy to get wrong.

Or maybe I'm just overcomplicating it, and the API as-is is just fine, or "as 
good as it gets".

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9


More information about the Active mailing list