Hi Ulf,
thanks for the prompt reply !
So for avoidance of doubt: none of the objects for which the
`QJSEngine::CppOwnership` flag is set will actually be deleted, right ?
Rather, only any QML references will be cleared, so the next access will
have to call my `create()` function again.
If that's
Hello,
as per the Qt documentation (
https://doc.qt.io/qt-6/qqmlengine.html#QML_SINGLETON), I'm using a static
`create()` function to inject an existing C++ object as singleton into the
QML runtime.
I'd like to be able to replace that singleton instance over the course of
the application's
elated issue outstanding:
> https://bugreports.qt.io/browse/QTBUG-115166
>
> As a workaround, use Ninja instead of Makefiles, since Ninja wasn't
> affected by these issues.
>
>
> Regards,
> Sze-Howe
>
>
> On Sun, Oct 29, 2023, 06:04 Stefan Seefeld wrote:
>
>> H
Hello,
I just started using the `at_add_qml_model()` function, where the "backing
target" is a (shared) library. I notice that each time I call `make`, the
target is rebuilt. Specifically, the sequence
```
Running moc --collect-json for target XXX
Automatic QML type registration for target XXX
_POP \
> QT_ANNOTATE_CLASS(qt_qgadget, "") \
> /*end*/
>
> /* qmake ignore Q_GADGET */
> #define Q_GADGET Q_GADGET_EXPORT()
>
> On 10/28/23 00:05, Stefan Seefeld wrote:
> > Hi Uli,
> >
> > thank you for sharing that document, that's indeed very helpful.
Hi Uli,
thank you for sharing that document, that's indeed very helpful.
Following its examples, I was able to set up my singleton such that both
runtimes (C++, QML) would share the same instance.
Doing that I bumped into what I would consider a bug, probably in the MOC
infrastructure:
The
On Thu, Oct 26, 2023 at 2:53 AM Ulf Hermann via Interest <
interest@qt-project.org> wrote:
> The very common misconception I keep reading over and over is that C++
> singletons should be the same as QML singletons. They generally aren't.
> You can shoehorn a C++ singleton into a QML one, but if
Hello,
I'm trying to "modernize" a large code base that just migrated from Qt5 to
Qt6.
Our code is using a few singleton objects that used to be exported into the
QML runtime via `qmlRegisterSingletonInstance()`. But as it is now
recommended to move away from `qmlRegisterType()` (in favour of
k, or am I still fundamentally
misunderstanding how to use QML with Qt6 ?
Thanks,
On Tue, Oct 24, 2023 at 2:50 PM Stefan Seefeld wrote:
>
>
> On Tue, Oct 24, 2023 at 10:47 AM Ulf Hermann wrote:
>
>> > In our existing code we call `qmlRegisterType<...>(...)` in our regular
lets me explore the
various aspects that are still unclear (e.g. C++ -> QML type name mapping
etc.)
Thanks,
On Tue, Oct 24, 2023 at 11:22 AM Nils Jeisecke
wrote:
> Hi,
>
> On Tue, Oct 24, 2023 at 4:35 PM Stefan Seefeld
> wrote:
> > So it sounds like I still
On Tue, Oct 24, 2023 at 10:47 AM Ulf Hermann wrote:
> > In our existing code we call `qmlRegisterType<...>(...)` in our regular
> > C++ code (e.g., some shared libraries that the main application links
> to).
> > I thought that, to be able to use those types in stand-alone QML code,
> > I'd need
On Tue, Oct 24, 2023 at 10:11 AM Ulf Hermann wrote:
> > Most of the context would be injected into the QML runtime from C++ via
> > calls to `setContextProperty()`, as well as by defining additional QML
> > modules from C++ (via `qmlRegister...()`).
>
> This is where your architecture fails. By
Hi Ulf,
thank you for following up !
Yes, it's entirely possible I'm missing something fundamental, trying to
approach a problem from the wrong side, so let me give some context:
We are developing an application that's written mostly in C++ with a GUI
done in QML. The application architecture
Hello,
I'm trying to create a QML extension module using CMake, and I've run into
some road blocks.
I want to create a QML module including a "plugin", based on my own code
rather than an auto-generated plugin stub.
I assume I'll have to define my own plugin target and then use
Hi Jeremy,
thank you very much for following up !
On Fri, Sep 22, 2023 at 6:36 PM Jeremy Katz wrote:
>
> I went searching for Qt 6 references to QCoreApplication.quit, as this
> has changed from Qt 5. Qt 5 makes no promises.
> https://doc.qt.io/qt-6/qcoreapplication.html#quit says:
>
Hi Jeremy,
thanks for the quick reply !
On Fri, Sep 22, 2023 at 1:16 PM Jeremy Katz wrote:
>
> On 9/22/23 09:35, Stefan Seefeld wrote:
>
> > 1. run the above command, but click the "quit" button immediately. Thus
> > results in the error message `QObject::killTime
Hello,
I'm trying to establish a Python test methodology whereby a QApplication is
launched (and its event loop executed) in a secondary thread, while the
primary thread performs some "test scenario".
Summary: I'm unable to set this up, and it isn't clear why this isn't
working.
Details: please
into the function the warning goes away.
Does this suggest that PyQt5 itself instantiates a QApplication as a global
object ?
On Tue, Mar 28, 2023 at 4:16 PM Thiago Macieira
wrote:
> On Tuesday, 28 March 2023 06:16:52 PDT Stefan Seefeld wrote:
> > First I see
> > the error /
Hi again,
It looks like the problem is that pyqt5 creates some hidden Qt objects very
early (i.e. upon importing some modules). If I move the imports as well as
the `MainWindow` definition into the secondary thread, everything appears
to be working fine.
On Tue, Mar 28, 2023 at 9:16 AM Stefan
On Tue, Mar 28, 2023 at 3:04 AM Samuel Gaist wrote:
>
> Did you consider the use of pytest-qt[0] ?
>
I did indeed, but it seems its functionality isn't entirely suitable for my
needs: I really do need to run the event loop continuously in the
background (rather than occasionally running
Thanks all for the quick follow-up !
It's good to hear that what I have in mind *should* work. However, I'm
actually struggling a bit with the implementation. I have attached a very
simple test-case creating a simple (pyqt5) app. If I call the `main()`
function rather than `run_app()` directly,
Hello,
I'm working on some Python tests that interact with a Qt application. I
would like to run the application's event loop in a secondary thread, so
the primary thread can perform the test itself.
I read in the past that such a use-case wasn't supported by Qt, but I can't
find that
Hi Volker,
On Wed, Feb 8, 2023 at 11:20 AM Volker Hilsheimer
wrote:
>
> Hi Stefan,
>
>
> Where do you see the advantages of synchronously waiting for a state to be
> reached, when instead you can connect to the respective state’s entered()
> signal? The former might make your code look more
Hi Roland,
thanks for your feedback !
I partially agree with your analysis. In particular, I'm not entirely sure
why the entire application logic needs to gravitate around a single event
loop. For user-input events this of course makes sense, as they are
naturally ordered and so conceptually we
Hello,
I haven't got any response to my question, but as the answer may really
help us simplify our code I'm sending it again.
Thanks for any help !
On Tue, Nov 22, 2022 at 9:02 AM Stefan Seefeld wrote:
> Hello,
> we are using Qt State Machines in a number of places in our applic
On Mon, Jan 9, 2023 at 7:10 PM Thiago Macieira
wrote:
The reason is what I stated: the qt-everywhere package is not as
> well-tested
> as the individual modules that compose it. The modules are tested on a
> daily
> basis by the CI. The everywhere package is not.
>
Yes, I understand what you
package.
On Mon, Jan 9, 2023 at 3:00 PM Thiago Macieira
wrote:
>
> On Monday, 9 January 2023 09:14:16 CST Stefan Seefeld wrote:
> > lrelease error: cannot create
> > '/home/user/srcdir/qt-build/build/qtbase/share/qt5/translations/qtwebsockets
> > _en.qm': No such file
Hi Axel,
I don't think I'll need web sockets (for now). Still, I tried configuring
with and without "-skip qtwebsockets", and both variants failed the same
way.
In fact, the configure step (even with using "-skip qtwebsockets" !) yields
-- Could NOT find Qt6WebSockets (missing:
-qtwebsockets_en.ts] Error 1
On Mon, Jan 9, 2023 at 9:51 AM Axel Spoerl via Interest <
interest@qt-project.org> wrote:
> We're testing Ubuntu 22.04 at present.
> Can't confirm a date though.
> --
> *Von:* Stefan Seefeld
> *Gesendet:* Montag,
sues.
> However, if compiling w/o websockets is the goal, wiping the build tree
> and deleting websockets from the source tree is likely to help.
> Sorry for accidently squashing both issues together.
> Cheers
> Axel
> ----------
> *Von:* Stefan Seefeld
> *
ing for me, 3.24.3
> should also work).
> Brgds
> Axel
>
> --
> *Von:* Interest im Auftrag von Stefan
> Seefeld
> *Gesendet:* Sonntag, 8. Januar 2023 23:57
> *An:* interest@qt-project.org
> *Betreff:* [Interest] Could NOT find Qt6WebSo
I'm trying to compile Qt 6.2.6 from source (using the
qt-everywhere-src-6.2.6.tar.xz
source package) following instructions from
https://doc.qt.io/qt-6.2/build-sources.html, and I get the following error:
-- Could NOT find Qt6WebSockets (missing: Qt6WebSockets_DIR)
> CMake Warning at
>
I'm trying to compile Qt 6.2.6 following the instructions in
https://doc.qt.io/qt-6.2/build-sources.html, with cmake version 3.25.1
The `configure` step fails with
Unknown CMake command "check_for_ulimit".
Is this a known issue ? I can get a little further commenting out line 63
in
Hello,
we are using Qt State Machines in a number of places in our applications to
manage object states for certain types of objects. Occasionally I would
like to use and manipulate such objects in a non-event-driven context, i.e.
without a running event loop.
Short of a StateMachine function that
34 matches
Mail list logo
