Guts of active-settings

[Ben Cooksley]

On Wed, Dec 21, 2011 at 1:51 AM, Sebastian Kügler <sebas at kde.org> wrote:
> Hey all,

Hi Sebas,

>
> [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.

I guess you are referring to the modules themselves here, as they are
a little bit of a mess. The app itself is fairly cleanly coded though
:)

>
> 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.

Even though a tablet or phone has much less to configure you are still
likely to run into the need to group certain panels, so I would
recommend coming  up with standards on how configuration panels are
grouped.

This is something that really does need a usability expert, and is
something System Settings itself has never really gotten.

>
> 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.)

One question: given that QML is supposed to be the future of Qt based
interfaces (with just the QML changing as the form factor changes)
perhaps it might be worth looking at how KCModule can be tidied up
(considering it is practically untouched since KDE 3 times) to
accommodate QWidget and QML based modules (as there is no point in
duplicating work, and i'm sure some things will bleed across between
Plasma Active and other form factors including the desktop)

>
> Cheers,
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9

Regards,
Ben