One option I just thought of (although convoluted) is keeping your original
library as-is and then making a QML module containing not much more than
headers with structs that declare QML_FOREIGN over just the types that need
to be used in QML. Those headers can be in the same folder as the QML
modu
Hello Stefan,
I was certain I could help you so I recreated your scenario - and found the
same problem.
I tried many different ways of coaxing the include path to be visible to the
type registration system - all in vain.
So I started digging around in code reviews, docs, forums and the like. Tu
f much more
power, flexibility and productivity.
I do hope you get your project into the shape you need. It does sound like but
of a pickle at the moment but it is not going to be difficult to get you
straight so do not fear or get frustrated.
We will get you there!
___
I have been watching the progression of this...
Ulf is right. I've had this out with him many times inw writing and in person
due to our out "strange non conforming" repository setup.
However in our case, we do not reak any of the proper QML Module boundaries so
once we apply the various allowed
he app).
I also just tried the calqlatr example, replacing the only import of
QtQuick.Controls i found with QtQuick.Controls.Material and adding my debug
code for printing styles. The result is import of the imagine, basic and fusion
style, but surprisingly not material.
I'll try to set
The only one which "might" look the same is Qt5 Default and Qt6 Basic (same but
renamed). But otherwise, no. You may be better to make a custom style defined
for your specific use case so you can be confident in your assumptions.
However, doing that itself has a different approach in Qt5 and Qt6
Hi Adam,
How are you using the styles in QML?
Are you importing QtQuick.Controls (only) or are you using specific style
imports?
Which version of Qt? CMake assumed?
Assuming the latter and at least Qt 6.2, CMake will only build in the libraries
it absolutely needs. But for this to be the case,
If your sources are intended to be part of the QML module, that is, available
to QML having imported Main_Module, then you should put your sources under the
module. If the sources are just assistant to your main.cpp and have no need to
be used in QML then they can go under the application.
Sourc
__
From: Ulf Hermann
Sent: Thursday, October 26, 2023 7:53:17 PM
To: Mike Trahearn ; interest@qt-project.org
Subject: Re: [Interest] sharing singleton instance between C++ and QML
> For the record it is actually possible (I proved it) to create multiple
> instances of the same singleton
Hi Ulf,
You have mentioned this foot gun (the create method ) to me before also. But
you have only ever broadcast your dislike for the gun. Please could you explain
why it is not a good idea to have single singletons.
So far your "duplicate it in a wrapper" is not very nice way for maintenance b
You may wish to take a look at the original drawing code for inspiration.
Obviously to replicate this with "modern" components would take a little
thought but certainly not out of reach.
https://code.qt.io/cgit/qt/qtquickcontrols.git/tree/src/controls/Styles/Base/StatusIndicatorStyle.qml
Most o
Hi Glen,
The old Status indicator had a Qt Quick Controls v 1 dependency which of course
is now deprecated so this could be a reason why it didn't "make the leap".
I had some trouble a few years ago with it when doing some iOS porting with
regards to that older dependency.
Seeing as it is a vi
12 matches
Mail list logo
