The way Plasmoids currently create user interfaces for configuration is not really what one would hope it to be. We have set out to fix this for Plasma Workspaces 2 and today after some back and forth between Marco and myself, we are edging closer to what could well be a solution as near perfect as one could hope for. Before showing what we've come up with, let me explain how it works right now.
The current system was really designed for components written in C++ and coming from the world of QWidgets. At its most basic, a Plasmoid written in C++ would create a configuration interface "by hand" in the C++ code full of QPushButtons and the like. If they were fancy, they'd use Qt Designer to visually design the interface and then the build system would generate the code from that. If the developer was going for the extra brownie points, they may have used KConfigXT files which describe the configuration data using XML. This too would be converted at build time into C++ and compiled into the C++ library containing the component.
This was ultimately very flexible. The Plasmoid could do whatever it wanted, after all. However, it meant that we required compiled C++ code at some point. This was obviously at odds with the design goal of Plasmoids that came in the form of architecture independent script bundles.
So I wrote a small class that took the KConfigXT XML and parsed it into the same kind of object that the kconfig_compiler helper tool did. We then used Qt's ability to load Qt Designer files and create user interfaces at runtime and, voila, we had the ability to show a configuration interface from a scripted Plasmoid with zero C++ code.
There were two downsides to this. First, it meant that the developer had to learn how to write a KConfigXT file (Plasmate helps automate that, at least) and how to use Qt Designer. Normally this wouldn't be too much to ask, but we're trying to keep the barrier to entry low and the Plasmoid developer had just gone through the trouble of learning QML and/or Javascript to get this far. So this was not great.
The real problem, however, was that the scripted Plasmoid had no ability whatsoever to interact with the configuration interface. It was simply a static thing that got shown to the user on behalf of the Plasmoid by libplasma. This means that if the Plasmoid needed to create widgets on the fly, populate lists or comboboxes with data from the Plasmoid itself, validate data and more .. there was very little it could do. This prevented some Plasmoids from being QML only and forced C++/QML hybrids in some cases simply because of the configuration dialog.
With libplasma2 and Plasma Worskpaces 2 we decided to Do The Right Thing(tm) and see if we could make it possible to write configuration pages in QML. Keep in mind that we want to still be able to load KControl modules where needed, as seen in the device notifier configuration dialog, and that we want them to look like normal everyday configuration interfaces.
After some back-and-forth between Marco and myself on the mailing list and in the plasma-framework repository, we have accomplished this. Now one can put a config.qml file in contents/config/ and define each page that appears in the configuration dialog:
import QtQuick 2.0
import org.kde.plasma.configuration 0.1
ConfigModel {
ConfigCategory {
name: "General"
icon: "plasma"
source: "configGeneral.qml"
}
ConfigCategory {
name: "Page2"
icon: "stuff"
source: "whatever.qml"
}
}
The configuration defined in the KConfigXT XML is then automatically connected up with the UI, just as it does in the QWidget/C++ case. When the user is done, the config object in the QML with all the configuration options is updated and thanks to the magic of property binding in QML the changes are then automatically propagated to wherever they are being used. This greatly simplifies configuration change handling and makes it much more declarative and therefore feel more at home in QML.
The source property in the ConfigCategory items refer to QML files in the package; names of KControl modules will also be supported. This means that the developer only needs to content with QML and they have full interactive control over the configuration UI. With QML Components, it looks the same as a QWidget based layout.
This also means that now the configuration UI can also be adapted automatically at runtime to fit the form factor. On Plasma Active a touch friendly interface can be presented while on Plasma Desktop a mouse and keyboard focused interface can be shown. All that needs to be done is to create a touch directory in the Package with any specializes in it. Even without that, the QML Components themselves will be the touch or desktop variety, which already improves things dramatically.
There is some work left with the KConfigXT runtime loader. I need to make it possible to use a given KConfigXT file as a template of sorts, so that one can define a set of configuration entries which can be duplicated multiple times in uniquely named groups. This is useful for things like launchers, for instance. In fact, Kontact uses KConfigXT in this way in places in it's C++/QWidget code.
The scaffolding is now in place, however, and it essentially works.
This means that a Plasma Workspaces 2 release will require some additional work. We will need to "port" existing Qt Designer based configuration interfaces to QML. That should be rather easy, however, and perfect as an entry-level job for those looking to dip their toes into the QML waters. We're keeping a set of documentation of what needs doing and what has changed as we make these kinds of changes. Once plasma-framework is in a slightly more solid state we'll start inviting people like you, kind reader, to get involved with a variety of fun and easy tasks so that we can put out a Plasma Workspaces 2 release as quickly as possible once Frameworks 5 is released.
