Guts of active-settings

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


Hey all,

[CC:ing Ben Cooksley, systemsettings maintainer, as he'll much like have ideas 
or concerns around it.]

In this email, I'm explaining a bit how the active-settings app works, and how 
it can be extended, and how it should be used.

Please also take note of my earlier email about QML bindings for KConfigGroup, 
which seeks a better solution for the configuration reading and writing 
mechanism we're using internally.

Alrightie, so active-settings is a small QML shell (Active App) that hosts 
configuration models. It's basically kcmshell4 / Systemsettings in a QML 
world. It's of course designed for touch devices, it uses the Plasma QML 
Components (so it adapts itself to the type of device it's run on, currently 
touch or desktop).

Upfront: Existing KControl KCMmodules do not work in active-settings, it's a 
conscious depart from the world of QWidgets, and I'd really like it to become 
less of a monster than systemsettings.

On startup, active-settings queries KServiceTypeTrader in order to look for 
plugins that have the type "Active/SettingsModule". These plugins provide a 
QML package with the UI for the module, and an optional C++ library to load. 
The QML UI is loaded in the "content" part of the active-settings app, active-
settings exposes a few things to it, such as bindings for KConfigGroup. (This 
restricts usage of those bindings to modules run inside active-settings, which 
is I think a sensible restriction.

The C++ library (which is basically a QObject) has the role to expose the 
"more complicated stuff needed" to the QML module. Imagine reading special 
values from C++ libraries, doing KAuth magic to apply settings, basically 
anything that cannot be done, or is really hard / ugly to do in QML. If you 
don't need C++ for the guts of your module, just don't add such a library. If 
there is already one, you can specify its name in your metadata .desktop file, 
so re-using these things is rather easy. (Of course, these would need to be 
installed.

An example for a pure QML module is the webbrowser config, found in plasma-
mobile/applications/settings/modules/web. An example for a module with C++ 
part is the time configuration, under modules/time.

The QML parts of those modules are of course Plasma::Packages.

For the "shell" app, it's using a PageStackWindow, which right now has some 
kind of "tab bar" on the right. This "overarching layout" might look different 
on a smartphone or smaller screen device in the future, transparant to the 
module. The modules would need to take care of not using too much horizontal 
space (so they'd fit on a smartphone's screen), and be flickable vertically.

As this is essentially important Plasma Quick API, I'm interesting in 
suggestions for improvements, and of course review of the actual code and 
concepts, so we can start pushing it as "this is how you do config" to app 
developers.

It would also be cool, if we had an easy way to offer this kind of 
functionality to apps (so one can, in pure QML) write a configuration 
interface for ones app -- either by starting active-settings 
org.kde.active.settings.mycoolapp, or by embedding it somehow. (The former of 
course needing a mechanism to sync config across processes. Specific modules 
can be opened right away, by using the plugin name of module as argument to 
active-settings, much like kcmshell4. (It currently lacks the --list argument, 
though.)

Cheers,
-- 
sebas

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


More information about the Active mailing list