Active Settings: Modular, embeddable configuration

Plasma Active‘s goal is develop an elegant, Free user experience for the device spectrum, for example touch-based tablets. Active Settings is a modular application hosting configuration user interfaces for apps and the system.

With Plasma Active Two, we released a first version of Active Settings, an app that lets you configure a few key parts of your system, such as time settings, and options for web browsing. Plasma Active Two contains a first stable, but still fairly bare-bones release, with only two modules.

Plasma Active's Time and Date settings

Active Settings provides a one-stop shop for app and system settings, and an interface for developer to ship settings user interfaces with their applications, or extend Active Settings with custom, or vendor-specific modules. Active Settings is a shell that loads, and displays a number of modules, in order to add a module, the app doesn’t need any code changes. This is done using KDE’s plugin system and Plasma packages.

Embeddings settings modules

In order to achieve a higher degree of consistency, settings modules can be loaded both from the settings app, and directly inside applications. This is done using a new set of QML bindings, which provide a settings loader item. This item is designed to lazy-load the settings plugin, so you can avoid touching config files, or loading a complex UI on startup and rather do it when the UI is needed, keeping startup times of your app low.

Plasma Active's Time and Date settings

In the screenshots, you can see the web browser module running in the settings app. I’ve also integrated the settings dialog into the dashboard of the web browser, so you can easily change things while browsing. Settings are synchronized across applications.

Workflow and design

Active Settings modules get loaded into the settings app. Often you will find that embedding these pieces of UI into your app makes the workflow more natural, as it puts things into context, which means you don’t have to switch to another app to change settings, both is possible. One of the reasons we want to share this code between apps and the general settings app is to present a more consistent UI. Along with the work on the guts of Active Settings, Thomas Pfeiffer has started to work on a HIG, human interface guidelines for designing settings dialogs. These guidelines complement the implementation nicely, and will make it easier for developers to write apps that feel naturally integrated into the system.
One thing we’re implementing in Active is instant apply of settings, so you’ll only find those “apply” buttons very rarely (we’re still discussing a few corner cases).
Plasma Active's Time and Date settings Active Settings uses the new Plasma QML Components, providing a standard implementation of the Qt Components API. Plasma Components can appear in different variations, in Active we default to the touch-friendly components. This of course makes it easier to share settings dialogs across devices, as we can provide standard widgets optimized for a given input method, screen form factor, etc..

Writing a settings module

We have now made it very easy to write settings plugins. A new set of QML bindings allow loading and embedding dialogs by providing components for the shell and loading of the modules, and a few pre-made bindings for domain-specific settings (time for example). These bindings allow you to ship a Plasma package containing your QML code, data files, images, etc. with your application, and have it available both in the settings app, and also in your own application. You can write pure QML settings modules, and it is very easy to extend your module with C++ code, which is automatically loaded and can export additional functionality to your QML runtime. These plugins are in principle really light-weight with minimal build dependencies (basically QObject, KPluginFactory and kdelibs’ macros for plugins), so deployment is made rather easy. Even if you’re doing a QML-only app, you can still provide a compiled plugin for the settings with it.

The API is designed to be minimal, the plugins can be very light-weight, as they’re basically exporting QObject-deriven classes to the QML runtime. Of course you can go completely wild here. Plasma packages provide a loading mechanisms for “pieces of UI” written in QML. This mechanism makes it very easy to share parts of the UI across different applications. As these packages do not contain compiled code, they’re architecture independent, small and easy to share and deploy. I’ve described the whole process of writing your own Active Settings module on TechBase, so hop over there if you’re interested in more details.

Those familiar with kdelibs’ classes and frameworks such as KControl, System settings, KCModule will not be surprised that much of this architecture has been inspired by these fine shoulders of giants. :)

25 Responses to “Active Settings: Modular, embeddable configuration”

  1. BajK says:

    Cool :) Hoping this can sometime make the current SystemSettings mess on the Desktop a bit less worse :)

  2. tbscope says:

    These sliders are very difficult to understand.
    What is on/off true/false … ?
    At least put some indication around it what the state of the button means.

    With a checkbox, it was a little bit clearer. But a slider like this: does the blue color mean the statement is true? Does the slider on the right side mean the statement is true? Is this universal?

    • I believe the blue (or highlight colour in general) indicates that the option is activated. The “slider” does perhaps make it slightly more ambiguous than otherwise, but it’s a common enough concept used in both software and physical controls on devices.

      • tbscope says:

        The problem here is that it has no resemblance zith physical switches.

        With a physical select switch, there is text on both sides of the switch (or all positions if there are more than two).

        Here you select something by moving the switch in the oposite direction. That`s not intuitive.
        If nobody told me that the blue color means that the option is true, I would just put the switch to the side where the text is.

    • Pascal says:

      I agree that the sliders are difficult to understand. A checkbox is much more universal.

      The dials with the date would be easier to read if it had more contrast and or perhaps smaller font above/below the selection.

      Thanks for your great effort

    • Johan Ouwerkerk says:

      Yep the colour is the indicator. I guess this was taken from various phone UXes (such as the N9) that do pretty much the same thing.

    • Kollum says:

      I agree it is confusing.

      Would it be possible to add a tick on the slider when activated, and to leave the slider blank when deactivated ? That whould clear things out

    • Pieter says:

      I’d say an easy way to solve this is to put the universally used power symbols on the sliders: a 1 if it is switched on, a 0 if it is switched off. Together with the coloring (highlighting usually means on, although only highlighting might not be sufficient) this should be clear for everyone.

  3. Johan Ouwerkerk says:

    If I might make a suggestion: for web plugins the “enable plugins on demand” mode of Opera combines the best of both worlds. I’m not bothered by stupid Flash adds, but I can click on the plugin object if I want to watch the embedded flash video on a blog or something.

    • Eike Hein says:

      Of course KDE’s web browser Konqueror had that feature for at least a decnade, too :).

  4. riessmi says:

    Good work so long
    gut i agree with the sliders: checkboxes are simpler, smaller and More logical
    A switch indicates 2 states a checkbox only 1, which is true or false
    Same thing in config-file: value or state(true/false)

  5. Martin Klapetek says:

    I’m no UI expert, but looking at the screenshots – I think the “tick” button next to the line edit (the ‘Start page’) is way too big, imho it would look better if the button had the same height as the line edit and both controls’ top and bottom edges would be aligned.

  6. shamaz says:

    nice :)
    That made me think of the honeycomb setting screen.
    And now that I think of it… Active could also have an ‘about’ panel :×363.jpg

  7. Willy says:

    I look forward to getting a tablet with Plasma Active and greatly appreciate everyone working on all things KDE.

    But I have to say this: Those sliders for on/off settings and those spinners are a usability disaster.

    A slider on/off switch is completely unnecessary complication and overuse of gestures for something that can be perfectly done with a single tap. I bet this comes from iPhone and Apple wanting to stay away form tapping that can be done on any old touchscreen.

    Spinners are a good place to use gestures with kinetic effects, but those spinners are hard to read and visually out of place on otherwise flat UI (flat = positive thing). I think a touchscreen adapted spinner widget should look like it can be flicked to rotate between values (just like those in the image), but that visualization should pop up when the widget is touched.

    p.s. Popup calendar widgets for all date selects, no exceptions. :-)

  8. Lionel Chauvin says:

    “A slider on/off switch is completely unnecessary complication and overuse of gestures”

    An user can accidently activate a checkbox when he does a vertical scroll.
    As usually touch applications doesn’t scroll horizontally, an on/off switch is a better solution than a checkbox.

    • a says:

      You can accidentally activate the “Clear history” button in the screenshot above while trying to do a vertical scroll, you can accidentally hit the text field (and then a virtual keyboard appears unnecessarily). If I remember correctly from previous screencasts (I could be remembering wrong though), Plasma Active itself does scroll horizontally. The globe in Marble scrolls horizontally, so if you are hitting the screen at the wrong place, you could end up scrolling an on/off switch in a sidebar.

  9. Abe says:

    “These sliders are very difficult to understand.”

    Slide to the right to show green color(On), slide to the left to show red (off)

    It is well know green mean safe/go/on and red is danger/stop/off.

    • dot says:


      ““These sliders are very difficult to understand.”

      Slide to the right to show green color(On), slide to the left to show red (off)

      It is well know green mean safe/go/on and red is danger/stop/off.”

      This has nothing to do with colors, and those definitions are not universal.

      • Abe says:

        Are you saying the red/yellow/green traffic lights are not universal? What planet you come from?

    • markit says:

      So if you slide on the right and shows red, means that is “block” or that is in ok position (the red) and if I want to “block” I have to slide it to the left to hide (go over) the red part? Is like you have a two state, left is red, right is green, and you move the cursor over the part you want to activate, or over the part that you don’t want to activate?

  10. STiAT says:

    I’m amazed. PA looks so great that I think I will need to buy a Tablet to play with it :-).

  11. dot says:

    I see that KDE is adopting, like Gnome, those stupid slider things where it’s impossible to understand the state. They’re bad both form an ergonomic point and from a usability point of view. It’s just bad design. I bet we should thank Apple for this “marvel” of mediocrity!

    And those rotating calendar selecting things are not much better. Manual dexterity is a variable thing that disappears with age. Make like easier for everyone and stop using those flashy but unusable things.