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