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
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
