touchy settings UI architecture

[Aaron J. Seigo]

On Friday, October 14, 2011 13:02:19 Marco Martin wrote:
> * the logic of the seetings of a particular thing is done in QObjects: a
> setting will correspond to a qproperty

+1

> * to start them, let's start with the time and locale kcms, ripping all the
> ui out of them, just leaving the config files read/write parts

sounds good...

> * the time one reveals the need of specialized qobjects rather than just a
> binding over kconfing: it sets the system time and uses policykit for that

yes; to keep it simple in the common case, i'd suggest a standardized "here is 
the configuration" API with plugins providing additional special bits (such as 
system time adjustment) on an as-needed basis only.

> * a qobject to write in generic config files could still be written, maybe

this would be very simple to do. in fact, we already have a start of that in 
AppletInterface which provides config read/write via it's scriptable QObject 
methods.

a QObject that represents a config object (file) analog to KConfig that 
returns KConfigGroup-alike objects on request (and lists groups) would be 
simple to do.

another approach would be to use ConfigLoader from libplasma. it's a QObject 
thanks to KCoreConfigSkeleton being a QObject. this would give us the ability 
to use KConfigXT XML and if we added a few read/write methods to it that 
allowed for "random" writes without use of KConfigXT then we'd be golden.

alternatively, we could start out with the expectation that everything _can_ 
use KConfigXT and see where we end up with gaps and fill those as we find them 
with appropriate solutions.

my favorite approach of the above so far is the last one :)

we could eventually event do a nice KConfigSkeleton<->QML bridge just as we 
already have with KConfigSkeleton<->QWidget.
 
> * the settings module logic is a kde c++ plugin, that has all the properties
> for config options, plus a property that says the path of the root qml file
> extracted from the package

this could be in the .desktop file even? the plugin is the library (as usual) 
and the QML UI could be an additional entry. then there is no need to load the 
C++ plugin at all until needed and it is easy to test different UI's or re-use 
a UI with different C++ plugins.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/active/attachments/20111025/a3337bfe/attachment.sig>