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

List:       kde-active
Subject:    ConfigGroup QML bindings
From:       Sebastian =?ISO-8859-1?Q?K=FCgler?= <sebas () kde ! org>
Date:       2011-12-20 12:30:33
Message-ID: 1773977.arQnRmbMG8 () marvin ! vizzzion ! net
[Download RAW message or body]

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
_______________________________________________
Active mailing list
Active@kde.org
https://mail.kde.org/mailman/listinfo/active
[prev in list] [next in list] [prev in thread] [next in thread]