[Development] qmlcachegen and QQC2 styles

[Nicolas Fella]

Hi,

On 10.05.24 16:43, Fabian Kosmale via Development wrote:
> Hi Nico,
>
> does this actually affect only your applications, or also libraries?

it also affects libraries like Kirigami, which doesn't assume any
particular style.

> And are the affected applications compiled differenrtly for desktop
> nad mobile platforms, or are the binaries shared?

For Android we have separate binaries, so there a compile-time solution
would work. For Plasma Mobile the binaries are usually shared with the
desktop variant of the distribution. The style is selected via the
QT_QUICK_CONTROLS_STYLE environment variable.

> 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
>>
>