General and Desktop

FYI - decided that investing in two 40in 1080p monitors of the same type was the easier solution. Problem solved. LOL

I think another important consideration is why you are sending the image as a text json object over a socket. The sockets can accept binary data. send it as a series binary chunks, including some control meta-data like dimensions, pixel bit format, and checksum. That will drastically decrease your storage requirements. As a rule nothing wrong with sending integer data in binary over the net. Where is gets crazy is sending floating point data over a network.

@Christian-Ehrlicher - Thank you. @mrjj - I found the QStringList on SO and already have it in place. Thank you both for your help.

@JonB said in Passing QObjects across threads via signals and slots: does this mean in practice that you cannot pass a QObject from a signal to a slot? Yes, you can. QNetworkAccessManager::finished(QNetworkReply*) is one such signal; QNetworkReply is a QObject. Since you are all saying that neither & nor * are good for QObject across threads Hold up. Take a deep breath. Let's untangle things a bit. You cannot use const QObject& as a signal/slot argument between threads, ever. Because QObjects are not copyable. You can use QObject* as a signal/slot argument between threads. @Christian-Ehrlicher and @mrjj did not say it's not allowed; they said it's dangerous. I am getting very lost now. Because when people ask "how do I pass the widget which caused a signal to the slot if that's what I need to do" one of the possible answers we give is "write a lambda which accepts the widget as an extra parameter", like: connect(checkbox, &QCheckBox::pressed, that, [checkbox]() { qDebug() << checkbox; }); Well, there's no multithreading here. So it's not dangerous.

[Side discussion forked to https://forum.qt.io/topic/125858/passing-qobjects-across-threads-via-signals-and-slots ]

I'm back once again. Don't beleave it myself though. After a little bit more experimentaion the following knowledge is obtained: this bug is NOT only with custom mesh but with any mesh (even from Qt3DExtras) it seems to have something with bounding volume: in the function bool HierarchicalEntityPicker::collectHits(NodeManagers *manager, Entity *root) (pickboundingvolumeutils.cpp) line 786 :queryResult = rayCasting.query(m_ray, current.entity->worldBoundingVolume()); line 787: if (accepted && queryResult.m_distance >= 0.f && (current.hasObjectPicker || !m_objectPickersRequired)) the if statement is not fullfilled for small volumes. The worldBoundingVolume() returns structure with m_raidious == -1 (but the object being clicked is perfectly fine) Maybe developers could spend some time and debug it as they understand what's going on much better than I do. Also some workaround for the current Qt 5.15.2 version is appreciated!

@Bonnie finger crossed, QSslSocket::supportsSsl(); using the build compiled with OPENSSL_PREFIX seems to return true, so i'm pretty optimistic about the thing that it should work properly! I don't know if i'm finally out of that nightmare but a huge THANKS in any case

Hi, I'm just evaluating Qt Charts for a similar use case that your are describing. Did you solve the issue in the meantime? An idea might be that you track the different multiples of your sampling rate. So if Line1 has 100 and Line2 has 20 you have a factor of 1/5 that gives you the index of Line2 in case you Crosshair cursor is linked to Line1. If your sampling rate is not certain multiple you probably can only do a search for the right index given from the (time?) value of the x-axis. I haven't checked other Qt Chars possibilities yet. Maybe there is a sort of tracker mechanism that allows you to do so. Some other people answered to similar questions that this example https://www3.sra.co.jp/qt/relation/doc/qtcharts/qtcharts-callout-example.html might be a good starting point for a solution. Please let me know if you found a good approach. Best Regards Markus

Yes. Painting inside a table/list (and outside a cell) is something I've never seen before.

@JonB Thanks for the clarity information. I was thinking the same .

First of all, what the others already suggested is correct and works fine. However, I myself find it to cumbersome to introduce a slot for this. There is a way to execute some function in the context of the event loop of a different thread (ui code has to be executed inside the main thread): QMetaObject::invokeMethod(qApp, [](){ QMessageBox::warning(...); }); Just make sure to not capture anything by reference in the lambda to avoid lifetime issues.

@Alvein Create a QWidget containing what you want to put into MainWindow and these Entities. Then you can edit this QWidget in designer and you can add it to your entities and MainWindow as you like.

@mrjj This is very resourceful and informative. I got my answer. Thanks!

@SGaist Thank you for your suggestion. I will try what have you suggested. many thanks.

@satyanarayana143 said in Qudpsocket: I will stop sending Do you mean you do not want to stop sending but for some reason it stops? Then please show your code. keepalive does not make sense for connectionless protocalls like UDP as already stated and your problem is most probably in your code.