Investigate how styles using native APIs fit into the Lighthouse abstraction layer.

This includes the styles on Windows and Mac, and potentially QGtkStyle on Linux. They potentially need to be moved out of QtGui and into plugins, and we need to investigate whether they can use the QPlatformNativeInterface::nativeResourceForWindow() API, or if some more support APIs are needed in Lighthouse.

Decision: Styles stay in QtWidgets for Qt 5.0

Discussion:

The styles can either be brought forward as a theming API for Qt 5 or as a QWidget styling API. The Qt Quick desktop components shows that QML components based on QStyle is feasible. At the same time the current QStyle API and implementations have ties to QWidget which are not appropriate for a general Qt theming API.

It is desirable to:

• Keep existing styles working with Qt 5 widgets
• Keep Qt 4 style sheets working
• Have QML desktop components for Qt 5
• Re-use the existing styles for QML desktop components
• Have something up and running sooner rather than later.
• Long term, it must be possible to create styled Qt Quick desktop apps that does not link against QtWidgets

Option 1: Keep QStyle as-is, create a new theming API for desktop components.

QStyle and subclasses live unmodified in QWidgets and are bug-for-bug compatible with Qt 4. QML Desktop Components initially use QStyle from QWidgets, but can be ported to use a new theming API later on to remove the widgets dependency. With this option QStyle is not a part of the platform theme API.

With this approach development and maintenance of the theming APIs happens separately.

It might be possible to create bridges between the APIs.

Option 2: Gradually move to widget-less styles.

QStyle would then have QWidget* in its API (which is horrible), but it can be forward-declared as the actual widget usage only happens in the platform theme plugins. Theme plugins and styles that want to stop linking to QtWidgets can be ported to not use the QWidget pointer. This porting probably involves adding new style options and also modifying the QStyle users (widgets) to set
the options.

QML Desktop Components can initially create fake widgets like it does today, but as the styles ports away from widgets it can stop doing so. We can add a flag to QStyle to indicate if a particular subclass requires widget pointers or not.

With this approach development and maintenance of the teming APIs happens in a single code base.

Option 3: A clean break from QWidgets in QStyle

Remove the QWidget pointer from QStyle entirely, bake the missing hooks into QStyleOption and break source compatibility somewhat for external QStyles. (very few apart from Oxygen)
It would require more porting effort but it is probably the cleanest approach and also exactly what Gtk did for their 3.0 release. QStyle users (widgets) will have to be ported to use style options instead of widgets.

This approach also allows development and maintenance of the theming APIs happens in a single code base.

• QStyle location
  For option 2 and 3 QStyle needs a new home, which can either be QtGui or a new QtDesktop library/module.
  QtGui is the simpler option, but adds overhead for non-QStyle users. This overhead is unknown. (depends on the QStyle dependencies.) QtDesktop gives free reign to include what's needed, but then we have an extra library.

• QStyle separation issues:

• The widget pointer
• Direct dependencies on QIcon and QSizePolicy in QtWidgets
• QStyleOption uses enums from widgets
• Generally the style implementations depend on widgets