Simply the most polished, fast, flexible, beautiful and elegant desktop, ever.
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.
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.
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).
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. :)