Re: [Interest] Signals, slots before the event loop starts?

[Thiago Macieira]

On Thursday, 11 April 2019 06:44:40 PDT Jason H wrote:
> Thanks! If it's that easy, and more reliable, why doesn't qApp->quit() do it
> that way?

Because it is not "quitLater", it's "quitNow". The difference between those 
two things is the sequencing of the event loop interruption compared to other 
events, both those that have been received but not yet processed, and those 
being received right now. And the overhead, of course.

Your idea is valid, but it's not how the behaviour is today. Changing the 
behaviour could break existing applications. If you can easily do what you 
want with a simple QMetaMethod::invokeMethod call, I don't think we should 
change the existing function.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] App crashes on iOS when geocode or reverseGecode is used

[Roman Wüger]

Hello,

I try to get the city and country from coordinates.
For this I use the functions geocode/reverseGecode. The pointer is valid but if 
the function is accessed with valid coordinates from the GeoPositionInfoSource 
signal,  I get a EXC_BAD_ACCESS

I use “osm” as the geo service provider.

Any hints?

Regards
Roman
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Signals, slots before the event loop starts?

[Jason H]

You are indeed correct. I am iterating on a minimal test case and the first versions do work. I'm working back to the minimal case that I experienced the issue. This may take some time though.

 

Thank you for your help

 

 

Sent: Thursday, April 11, 2019 at 10:07 AM
From: "Konstantin Shegunov" 
To: "Jason H" 
Cc: "Konstantin Shegunov" , "Interests Qt" 
Subject: Re: [Interest] Signals, slots before the event loop starts?



On Thu, Apr 11, 2019 at 4:57 PM Jason H  wrote:





Update on this:

It didn't work. I called it, nothing (discernable) happened. Got a bunch of serial port not open errors





Something else's amiss. Here's the test-case:
 

#include 

#include 

 

int main(int argc, char *argv[])

{

QCoreApplication app(argc, argv);

 

QObject::connect(&app, &QCoreApplication::aboutToQuit, [] () -> void  {

qDebug() << "Goodbye cruel world!";

});

QMetaObject::invokeMethod(&app, &QCoreApplication::quit, Qt::QueuedConnection);


 

return QCoreApplication::exec();

}



Which produces (as expected):



17:05:37: Debugging starts

Goodbye cruel world!

17:05:38: Debugging has finished







___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Signals, slots before the event loop starts?

[Jason H]

Update on this:

It didn't work. I called it, nothing (discernable) happened. Got a bunch of serial port not open errors

 

Sent: Thursday, April 11, 2019 at 9:44 AM
From: "Jason H" 
To: "Konstantin Shegunov" 
Cc: "Interests Qt" 
Subject: Re: [Interest] Signals, slots before the event loop starts?




Thanks!  If it's that easy, and more reliable, why doesn't qApp->quit() do it that way?

 

 

Sent: Thursday, April 11, 2019 at 8:54 AM
From: "Konstantin Shegunov" 
To: "Jason H" 
Cc: "Giuseppe D'Angelo" , "Interests Qt" 
Subject: Re: [Interest] Signals, slots before the event loop starts?



On Thu, Apr 11, 2019 at 3:48 PM Jason H  wrote:


What is the best way to do that? I think in the past, I used a 0ms timer, but that always feels janky.


QMetaObject::invokeMethod(qApp, ::quit, Qt::QueuedConnection);

is my preference.







___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Signals, slots before the event loop starts?

[Jason H]

Thanks!  If it's that easy, and more reliable, why doesn't qApp->quit() do it that way?

 

 

Sent: Thursday, April 11, 2019 at 8:54 AM
From: "Konstantin Shegunov" 
To: "Jason H" 
Cc: "Giuseppe D'Angelo" , "Interests Qt" 
Subject: Re: [Interest] Signals, slots before the event loop starts?



On Thu, Apr 11, 2019 at 3:48 PM Jason H  wrote:


What is the best way to do that? I think in the past, I used a 0ms timer, but that always feels janky.


QMetaObject::invokeMethod(qApp, ::quit, Qt::QueuedConnection);

is my preference.






___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] [qmake] COPIES broken for recent QT?

[Olivier B.]

I just noticed that my COPIES fail in Qt 5.11.1+ in visual studio
solutions. This seems caused by the change in
mkspecs/features/file_copies.prf; to use $(QINSTALL) instead of the
previous $$QMAKE_COPY.
But unlike in makefiles, QINSTALL is not defined in the visual studio
solutions :(
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Signals, slots before the event loop starts?

[Konstantin Shegunov]

On Thu, Apr 11, 2019 at 3:48 PM Jason H  wrote:

> What is the best way to do that? I think in the past, I used a 0ms timer,
> but that always feels janky.
>

QMetaObject::invokeMethod(qApp, ::quit,
Qt::QueuedConnection);

is my preference.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Signals, slots before the event loop starts?

[Jason H]

> Sent: Thursday, April 11, 2019 at 7:35 AM
> From: "Giuseppe D'Angelo via Interest" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Signals, slots before the event loop starts?
>
> Il 11/04/19 00:18, Jason H ha scritto:
> > In a QObject who is exported to QML, and is instantiated just below the 
> > top-level Window:
> > //  in the object's open() method:
> > if (!_serialPort.open(QIODevice::ReadWrite))
> > qApp->quit(); // won't actually quit - no use if I can't use the serial 
> > port. (because another instance is using it)
> >
> > Then I have a ready() signal that is emitted when the serial device is 
> > ready, however the QML, when I hook onReady, it never gets called. I have 
> > to use a Component.onCompleted at the top level. However, there is async 
> > serial I/O happening, so there is at least one event loop?
> >
> > What can I do to make sure these things work?
>
> Regarding quit(): calling it before exec() has been called yields no
> effects. This is documented:
>
> > https://doc.qt.io/qt-5/qcoreapplication.html#quit
>
> > If a signal connected (non-queued) to this slot is emitted before control 
> > enters the main event loop (such as before "int main" calls exec()), the 
> > slot has no effect and the application never exits
>
> So, instead of calling quit() directly, do a queued invocation.

What is the best way to do that? I think in the past, I used a 0ms timer, but 
that always feels janky.

>
> Regarding ready(): can't say more without looking at the code. You need
> to make a minimal testcase.

It's rather simple, port opens when the portname property is set during 
initialization. The device writes a ready message that i detect and emit 
(somehow... I don't know how I process it in readyRead handler without an event 
loop, but it happens). I emit ready() and the QML handler for ready does not 
get invoked.

> Anyhow, all events queued before running exec() will get dispatched when
> you enter the event loop. The problem with e.g. quit() is that it does
> not involve sending events at all, it involves setting a flag into the
> event loop. Flag that is never read because the event loop is not running...

That seems janky as well. Why not give it it's own message? Even windows has 
WM_QUIT.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Initialization of Buffer entity property in QML

[Volker Enderlein]

Thanks Jérôme for pushing me into the right direction.

Now I see where I went wrong.

The buffers data assignment must be done as follows:

data: { var vertexArray = new Float32Array([ -1., 1., 0., 1., 1., 0., 
-1., -1., 0., 1., -1., 0. ]); return vertexArray; }


Cheers, Volker

Am 10.04.2019 um 15:57 schrieb Jérôme Godbout:

The new is not something you should do into binding for sure. If I look at the 
Qml Buffer doc:
https://doc.qt.io/qt-5/qml-qt3d-render-buffer.html

Not much seem to be expose to Qml, syncData, usage
https://doc.qt.io/qt-5/qt3drender-qbuffer.html
and the sub class QBuffer offer the following properties accessType.

Seem like you will need to fill the data into C++ from what the doc is saying. 
Maybe  make your own QmlBuffer inherited class where you can expose QByteArray 
to expose the data, the dataChanged signal is already present. Just need a 
property exposure, wonder why this was not already exposed. You can make static 
Q_INVOKABLE to create QByteArray from JS array type into that class:
Q_INVOKABLE QByteArray MakeVector3F(const QVariantList& data);
Q_INVOKABLE QByteArray MakeVector2D(const QVariantList& data);
...
Maybe add the data type, so you could have a call that push/pop data into your 
buffer QByteArray

Q_INVOKABLE void pushData(const QVariant& data);

with the proper C++ call to convert the QVariant into the Buffer data type.

Those buffer class seem a bit anemic into functionality, wonder how they should 
be normally be used?!? The Qml exposure seem incomplete to me. Maybe someone 
with deeper knowledge can pitch in, but the only way I see it, they are fully 
managed into C++ only to be plug in Qml at best, no containing data 
manipulation into Qml from what I see. You use case seem legit to me, you have 
some property you need to assign to a Buffer, you probably don't want to do 
this with huge data set, but for simple and debugging buffer this will come in 
handy to do so. In the real world, making C++ producer to generate you data 
Buffer would be better performance wise.

I haven't play much with Qt3D, but we did a lot of rendering to texture at my 
previous place, and we did have a Qml Buffer implementation way before Qt3D and 
we did needed those data type and everything was named attribs to the rendering 
actor and we could set the shader programs (vertex, geometry, fragment...) from 
the Qml, we could attachs as many attribs Buffer and a draw call to the actors 
for the rendering. I would expect something similar for a real 3D rendering 
engine.

-Original Message-
From: Interest  On Behalf Of Volker Enderlein
Sent: April 10, 2019 3:48 AM
To: Qt Project 
Subject: [Interest] Initialization of Buffer entity property in QML

Hi,


in a QML file I try to initialize a property of type Buffer, but unfortunately 
it does not work.

There's no error but in the MyMesh Entity the vertices Buffer always has zero 
length.


import Qt3D.Core 2.0
import Qt3D.Render 2.0
import QtQuick 2.0
import Qt3D.Extras 2.10

Entity {
      id: root

      property Buffer vertices: Buffer { type: Buffer.VertexBuffer; data:
new Float32Array([ -1., 1., 0., 1., 1., 0., -1., -1., 0., 1., -1., 0. ]) }

      MyMesh {

   id: mesh

   vertices: root.vertices

     }

}

How is the correct way?


Cheers, Volker

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest



--

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest