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.
Related
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.
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.
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.
When you're prototyping a new system, what guideline(s) do you use to mark a stop-and-start-over point?
Typically I write prototypes as part of the architecture/design process, to answer questions that can only be answered by actually working with the code. For example, questions such as:
Can I do drag & drop in Silverlight?
What framework would I use to draw interactive canvas objects in WinForms?
Usually you can write a prototype fairly quickly to answer such questions. Obviously the code does not have to be production-quality, it just has to go far enough to answer these questions.
Once you run out of open questions, I would scrap the prototype and finish your "design". Then you are ready to begin creating a production version.
When the one I'm working on doesn't fit the requirements anymore (functional, usability, or otherwise).
Prototypes are meant to be a dispossable item so I never hesitate when throwing one away.
When you've de-risked the functionality to a level where you feel ready to write production code.