Unified Styling Architecture

The goal is to have the same tooling and APIs to apply styles on Widgets and Quick. That reduces the efforts on maintaining different implementations on hybrid applications and improves consistency.

The expectations from user perspective are:

• Re-use an already existing style from QWidget when integrating (or migrating to) QtQuick components. Although would be acceptable if a new implementation using the outcomes of this Epic is needed.
• No performance drop when using custom styles (also for startup time)
• Works with Figma bridge/import
• Can be used together with native styles
• Easy to maintain and scale

------------------------------------------

This solution is meant for (but not limited to) those that use both Widgets and Controls, and don’t want to implement the same style twice with different technologies. This is especially appropriate when mixing Widgets and Controls in the same application, but can also be relevant for those that offer a suite of both Widgets and Controls-based applications.

Such a system can, from one perspective, be seen as a toolchain that takes design input on one side, runs it through tooling, and produces styles for both Widgets and Controls as output.  This following is a list of technologies and solutions to consider for the different stages:

Design input

The following technologies can be used to design a style. They are not mutually exclusive, but the solution we end up with should support one or more of these.

1. Figma: Being able to design a style in Figma was the whole point with the Figma Style Generator. Whatever we come up with, being able to continue to do so will (most likely) remain an important strategy for the company, and therefore be a requirement.
2. CSS: This is another input technology to consider. It’s already well established as a styling language.
3. QML: Rather than implementing support for e.g CSS to describe a style, why not use QML as styling language?
4. YAML: KDE uses (among others) YAML as an input source in their Union project.
5. Controls style as input: Being able to take an existing style for Controls and produce a Widgets style from it.
6. Widgets style as input: being able to take an existing QStyle for Widgets, and produce a Controls style.  It’s uncertain if this feature is really needed?
7. Images produced from native controls: Using images from native controls on macOS, is something we already do. But today we duplicate this work for Controls and Widgets. So we should consider if there is a way to keep this implementation in one place (e.g a shared library) for them both to use. But this might be a requirement that is orthogonal to this Epic.
8. QtDS: Qt Design Studio could also be used for designing styles, so I mention it here. It can serve as a back-up solution if we for some reason cannot support Figma in the future.

API

The following is potential APIs we could consider implementing

1. Have a common library in Gui which main goal is to serve as a common place to store and provide style definitions for a particular component (a control or subcomponent of the control at a particular state for which style configurations need to be applied to). Style definitions consist of a set of relevant properties (eg: text properties, layout, colors, etc). These style definitions can then be accessed by both the widget and Quick styles in order to know how to draw the components. The Union project follows this approach.

Tooling

The following is a list of possible tools we could consider implementing

1. Style Generator: This tool is for those that want's to use Figma to design styles for Controls and/or Widgets. We have already implemented a first version of this tool.
2. Union: This is an ongoing project in KDE to be able to use a variety of different input sources (YAML, CSS) to create styles for both Widgets and Controls.
3. Controls-to-Widgets: This tool is for those that already have a Controls style, and want to use the same style for Widgets. Two directions are possible (and not exclusive):
   1. The first is to take snapshots of the controls in their different states, to produce images for a QStyle. This is not very different from what we already do with the macOS style (taking snapshots of native controls), and also not that different from producing an image based style from Figma. 
   2. The second (and more ambitious) way is to implement a QStyle that is basically a scene graph for Widgets. That is, we remove the usage of a backing store, and let QStyle instantiate QML controls (using e.g QQuickWidget) that match the widgets they represent. Custom widgets that cannot be represented by a Control will fall back to using QQuickPaintedItem. This solution will enable all the animations and effects from the Controls style, instead of using static images. This solution is meant for those that want to mix Widgets and QML in the same application, and therefore anyway depends on linking in QML. It's unclear if this solution is technically feasible.
4. Widgets-to-Controls: create tool that creates an image-based Controls style by taking snapshots of Widgets (or use the QStyle to paint to images). This use-case is for those that already have a custom Widgets style, and want the same style to be used for Controls.
5. Ahead-of-Time vs Compile-time vs Run-time: a tool we choose to develop can parse the input at different stages during the production and run-time of an app. And it seems like we might have different ideas of what should be done when. So this should be discussed.

Output

The output of the tooling process should be two styles, on for Controls and one for Widgets. The styles could be completely separate and self-standing, but it’s worth investigating if we (as an optimisation) can share assets and images between the styles, at least in the mixed QML/Widgets app case.