Qt Contributors Summit 2019 - QStyle
Jump to navigation
Jump to search
Future of QStyle
Ideas and discussion points
- KDE has been using existing QStyle styles with Controls 2 for a long time already
- 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:
- should be possible to keep QPainter-based styles working
- using the scene graph should also be possible
- using native platform widgets might be possible, but then you are creating rather than just rendering
- 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