I'm trying to make QTcpServer start a separate thread for each connection. There's example code available that does just that: http://doc.qt.io/qt-5/qtnetwork-threadedfortuneserver-example.html
This code works by subclassing QThread. If I build my code based on that example, I'm pretty soon running into "QObject: Cannot create children for a parent that is in a different thread." warnings.
There is documentation from Qt that advises against subclassing QThread, because that is "doing it wrong": http://blog.qt.io/blog/2010/06/17/youre-doing-it-wrong/
So, my question is, if the Qt provided example code is directly in violation of the Qt recommended practice, is there an example of the correct way to do it? Any example I've found so far subclasses QThread.
Qt is a developing product. And, I seem, subclassing QThread is still considered as legal practice. It is just an older technique, so old examples use it.
Your problem seems to be the wrong usage of QObject(s) across different threads, rather than QThread subclassing. First try to find the code which issues the warnings.
Related
I am using Qt5 to create a Qt application.
Following is my code:
static QStateMachine *myStateMachine = new QStateMachine(nullptr);
I wanna create the QStateMachine just one time， use the same machine all
the time.
However, I learn that all QObjects should not be instantiated before QApplication instantiated.You can read Qt document about QApplication's Detailed Description.
My question is:
Why all QObjects should not be instantiated before QApplication instantiated?
In a 2014 thread on the Qt interest list, Thiago Macieira wrote:
Qt is not supported before the creation of QCoreApplication. Your use-case is not supported, so no answer is necessary.
Just don't do it.
Note: the doc is wrong.
He's a long-term Qt maintainer (and worked for Trolltech). Thus I would generally follow his advice.
What I'd imagine he means is that on various systems--features end up needing some kind of chance at initialization. It may not be all systems, and it may be a need that gets introduced in a later version. The Qt developers thus likely reserve the right to make any given feature require it...and offer no promises that anything in the system will work before the initialization.
(Note: This sort of parallels the concept of undefined behavior in C++)
However, he softens the stance slightly in a later post:
Does that mean static objects aren't supported either?
Not supported, but mostly they work. We will also fix bugs in uses that reasonably could happen in main() while parsing the command-line and other set-up procedures before QCoreApplication gets created.
Just be careful because some things will not work. For example, QString::fromLocal8Bit doesn't work before QCoreApplication.
Point being that giving a list of things you can do before QApplication instantiation today should be considered misleading. They don't want to make that list.
If you find you really have to do it, and you appear get away with it, then be prepared to have it break in a future release (or perhaps even on a different machine).
I'm currently writing a programme which has a function to hash a number of files in the background. I've read the Qt4 documentation a number of times over and I still can't really figure out which threading option is best for this.
http://doc.qt.io/qt-5/thread-basics.html
There's really no need to update the GUI when it's done with each file, I just don't wish to block the GUI and I really only need a single signal/slot connection upon completion. I'm thinking of extending QThread for a hashing thread. Does this sound reasonable/right?
I have this article bookmarked as it nicely illustrates the use of QThread and highlights some common misconceptions about it. Sample code available, which runs without blocking the GUI. Sample is hosted on RapidShare, but they seem to have implemented some sort of timed waiting period since I last used it.
This sounds like a good place to use the QtConcurrent::map() function. The map function can apply the same operation to a container of objects, in your case, files. Once you start the map function, you can create a QFutureWatcher and connect to its finished signal to be notified when all of the work is done.
I'm pretty new to QT's graphic view frame, and I couldn't find anything about this in the docs or on Google.
I have a GUI application that draws a representation for some data. The application itself does some work with matrices / vectors (a neural net thing) and has to represent it on a QGraphicsScene. So far so good, but I've noticed that the app segfaults & crashes sooner or later (and usually sooner) if I try to update the QGraphicsScene from another thread. The QT Docs say nothing about thread-safety & Google gives nothing. What I want (and pretty much need) to do is run the calculations & update the GUI representation accordingly, but the GUI controls etc themself have to remain responsive. As I said, my first thought was to do the whole thing in another thread, but it crashes randomly if I try to.
Is there any "accepted practice" to do this kind of thing in QT or is there some gotcha that I don't know of in the graphics view framework itself?
The Qt docs actually say quite a lot about thread safety. If the docs for QGraphicsScene don't say anything it's because they are not thread-safe, consistent with the behaviour you are seeing.
What you need to do is run your calculations in another thread and synchronise that thread with the main GUI thread as appropriate. A simple way to do this would be to set a flag in the main thread when the calculations are ready for display. That way you can call the appropriate QGraphicsScene methods in the main thread at the right time by simply checking the flag.
I've given up on actually trying to make it go faster.
My biggest problem is that when I'm inserting the html, the application slows down to a crawl.
I have a progressbar, and I'm calling
QCoreApplication.processEvents()
(I'm using pyqt, by the way)
Can I put insertHtml() into a different thread, so I don't have an unresponsive interface?
How would I go about that? I've looked into QThread and QThreadPool, and I'm not quite sure where to begin.
I had this problem as well, here are a few things I did to make it faster:
TxtBrows->setAcceptRichText(false);
TxtBrows->setContextMenuPolicy(Qt::NoContextMenu);
TxtBrows->setOpenLinks(false);
TxtBrows->setReadOnly(true);
TxtBrows->setUndoRedoEnabled(false);
This should get rid of unneeded overhead.
Also when inserting large amounts of text its good to turn off screen updates:
setUpdatesEnabled(false);
TxtBrows->append(SomeBigHTMLString);
setUpdatesEnabled(true);
This was recommended somewhere in the Qt documentation but I can't find the spot just now.
[Edit]
I stumbled across the spot in the Docs (just in time for them to be outdated by QT5 grinn) http://qt-project.org/doc/qt-4.8/qwidget.html#updatesEnabled-prop
In GUI applications, the main thread
is also called the GUI thread because
it's the only thread that is allowed
to perform GUI-related operations.
-- from the Qt Docs
So, no. Unfortunately you cannot perform that operation in a thread.
Edit: Technically, it is possible. I just wrote a short snippet that did so, however using Qt GUI objects in that way is highly unsafe.
In the past I've had some experience of Qt in C++. I've now started using PyQt, and finding it a bit bewildering. There doesn't seem to be any definitive source of documentation, apart from a small amount at Riverbank. I guess the first thing I'd like to know is that there's an initial hump with PyQt, and it does get easier. [Edit: The main problem I was having was due to a typo - init not __init__. I'm not finding it so hard now :P]
The PyQt docs talk about new style signals and slots for PyQt, as well as old style. They suggest that the new style is better, but I was wondering if that is what most users of PyQt do.
Yes, that is. New syntax is more clear, so why not?
Note, that when you trying to connect slots by name, you must call connectSlotsByName explicitly, since there no preprocessor that will work before execution and connect them.
PS: Beside, C++ syntax for signal/slot connnection is just ugly, and old PyQt syntax was pretty similar without any reason, so I was glad to see this change in PyQt.
PS2: There was the question here recently about this, check it out.
For reference see: PyQt Class Reference - it's quite comprehensive and goes into details with examples. Most of the examples are in C++ and although I'm something of a Python newbee, I didn't find it difficult to translate into Python.
If you're an experienced developer and starting to use Python and PyQt, this is a pretty good book - about the only full scale book on the subject that I know of: Rapid GUI Programming with Python and Qt.
Signals and Slots: I always use the new syntax for signals and slots in PyQt, which is simple and elegant - much more 'pythonic'. PyQt is great, but in many respects it's still very C++ like - the more they do to 'pythonate' it, the better.