[Development] qmlcachegen and QQC2 styles

[Fabian Kosmale]

Hi Nico,

does this actually affect only your applications, or also libraries?
And are the affected applications compiled differenrtly for desktop nad 
mobile platforms, or are the binaries shared?

If you have only applications, and they are compiled differently, then
the answer would be to import a proxy module (let's call it 
QtQuick.Controls.KDE), which does nothing but import the correct style
for the platform.

However, that won't help you for the case of libraries. I guess one way
forward would be to teach qmlcachegen to treat any instance of a type
from controls as a type from QtQuick.Templates with the same name
[1]; that should after all define the API usable across styles – though 
that will
need some validation, especially with the "native" styles (e.g. Windows,
macOs). It would also most likely depend on 
https://bugreports.qt.io/browse/QTBUG-124670 being implemented, so that 
we can do that level of type adjustment without turning the compiler 
into a completely unreadable mess.

Regards,
Fabian

[1] It's not quite that easy though. If you have a
Templates.ToolButton object, it's an instance of Templates.Button.
If you have an QtQuick.Controls.Basic.ToolButton object, it is
_not_ an instance of  QtQuick.Controls.Basic.Button; so we
need to treat them at least as anonymous subclasses - which probably
promise to not shadow properties, so that types actually stay intact.

On 10.05.24 16:18, Nicolas Fella via Development wrote:
> Hi,
> 
> one of the documented limitations of qmlcachegen is that it cannot
> properly compile code that is using Qt Quick Controls. The
> recommendation here is to specify a style at compile time by directly
> importing it. This recommendation may be fine for some projects, but for
> us in KDE it poses a problem. For our applications we are maintaining
> two different styles that get used in different environments.
> 
> We have qqc2-desktop-style (which is a bridge to QStyle) for desktop
> platforms and qqc2-breeze-style (a standalone style mimicking the Breeze
> QStyle) for mobile platforms. Therefore we cannot hardcode one
> particular style on an application level.
> 
> Furthermore we are developing various QML-based library components where
> we do not want to assume that the user of the API is using a particular
> style.
> 
> This means that we are currently missing out on a lot of optimization
> from qmlcachegen, making for a very unsatisfying situation when moving
> to more modern QML practices.
> 
> I'd like to ask about possible ways forward so that we can fully benefit
> from qmlcachegen while keeping the ability to have different QQC2 styles.
> 
> Cheers
> 
> Nico
> 

-- 
Fabian Kosmale
Manager R&D

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
fabian.kosmale at qt.io
+49 1638686070