The previous blog post cited performance reasons as the motivation for having one fixed style. However, we have found a way to make multiple styles available without sacrificing performance. So far, two new styles have been merged, implementing both Google's Material Design and Microsoft's Universal Design.
It's important to note that these styles are not claiming to be native, but instead a 100% cross-platform implementation of the Material and Universal design guidelines. For example, the Material style does not adapt to any Sony or Samsung theme on Android. You can run these styles on any platform and they will look more or less identical.
We're also working on a neutral, optimised base style, and a fancier "Qt" style, both in cooperation with our designers.
Earlier, we talked about separating the C++ logic and the visual QML layer. Thanks to the feedback from our users, we have realized the power of a pure C++ logic layer and have decided to expose it separately for those wanting to build their own custom user experience. We've named this layer "templates". A template is the foundation of a control. They encapsulate the behaviour of controls and provide an interface for styles to do their thing, allowing a true separation of concerns. For an introduction to this concept, take a look at the following video taken from the 2015 Qt World Summit:
The styling system now uses a technique similar to file selectors to choose which style to load at application startup. There are currently two ways to choose the application style:
An environment variable:
The "-style" application argument:
A manifest file for specifying the preferred style and style-specific attributes is also being considered as a future addition.
The more complex beasts like TableView and TreeView are on our to-do list. We realise that these are some of the most important controls, remaining quite relevant even on touch devices. Given the great opportunity that we have (to completely redesign all of the controls), we'd like to take the time to design these particular controls to be as lean as possible. After all, they are typically showing the most data. Not using Loaders has already given us a substantial head start in this area.
Popups are also getting some love, with a new approach that uses Qt Quick items instead of native top-level windows. What this means is that:
All platforms will have full access to menus, even embedded systems that don't support multiple top-level windows.
Controls like ComboBox will be fully styleable, which was not possible with native windows in Qt Quick Controls.
Internal focus and key event handling is simplified.
It is easier to auto test things like menus, resulting in greater test coverage.
Popups will be bound to the window in which they were created.
Controls that will take advantage of this approach include Menu, ComboBox and PieMenu, with ToolTip also being considered as a new addition.
Finally, with the new infrastructure, we've decided to consolidate some of the controls from Qt Quick Extras into the module, resulting in one less import to remember. Not all of the controls made the cut, as we'd like to get an idea of which of these are in demand so that we can focus on the core areas of the module. Creating suggestions on our bug tracker (under the component "QtQuick: Controls 2") is a great way to let us know what you'd like to see as part of the offering.
Here's a small example of a Qt Labs Controls application:
import Qt.labs.controls 1.0
text: "Hello World!"
We will be releasing a technical preview of the new controls in Qt 5.6 (with the working title of Qt Labs Controls), with a proper release planned for 5.7. We've had some early adopters trying out what we have so far, and giving us feedback via the bug tracker, which is great! If you'd like to do the same, try out the latest Qt 5.6 snapshot.