Qt Contributors Summit 2019 - QStyle

Future of QStyle

Ideas and discussion points

• KDE has been using existing QStyle styles with Controls 2 for a long time already

1. continuing the way that Controls 1 did it

• QWidgets might or might not end up as a separate module
• rendering widgets into the scene graph, with option to customize the SG nodes for specific widgets in specific styles (showed the demo)
• QSkinny (showed the demo)
• maybe make QStyle the entry point for rendering a whole widget or control at once:

1. should be possible to keep QPainter-based styles working
2. using the scene graph should also be possible
3. using native platform widgets might be possible, but then you are creating rather than just rendering
4. We tell users that Qt Quick with the software renderer is fine; but switching from straight QPainter to QSG (when there's no GPU) is still some overhead

• something like Imagine style (9-patches mostly) for both widgets and controls

Possible requirements

• styles portable between Widgets and Controls
• accelerated painting for widgets too
• use the scene graph for both?
• reduce maintenance burden for business logic of controls and widgets
• native widgets or controls on some platforms
• ask the OS to modify palette colors based on background (macOS requirement)
• style designers should be able to tweak a constants table with more than just colors (way beyond QPalette): icons, line thickness, etc.
• deal with animated styles somehow

Possible outcome (something to try)

• just do what KDE does (as Controls 1 did it, mostly) but refactor QStyle API to make that work better
• split up into QGuiStyle with portable API, which QStyle inherits and makes it widget-specific
• one Controls 2 style (proxy) that uses QGuiStyle
• uncertain: combine QPlatformTheme, QStyleHints and QGuiStyle; or rename QStyleHints to QTheme