I have found several questions that looks similar to this such as:
Busy indication with PyQt progress bar
Progress bar with pyqt
Display installation progress in PyQt
But most of the examples and answers were on 1 GUI thread and 1 data processing thread.
Let me explain my scenario.
I have 3 classes:
class MainWindow (Inherited from QMainWindow class and act as main GUI)
class LogInWidget (Inherited from QWidget class.This class consists of all the username/password field + a progress bar, pls see the image below)
3.class DataTableWidget (Inherited from QWidget class.consist of a table that display a few hundreds thousands of data)
The program is designed so that once a user logged in to the program via LogInWidget, he will be able to see all the data displayed by the DataTableWidget.
I use .setCentralWidget method to set both LogInWidget and DataTableWidget.(ie.if the user password is correct, i use
table = DataTableWidget ()
self.setCentralWidget(table)
to display the table.
My problem is: When user logged in, there is a big GUI freeze before he can see the data table as there are so many data entry to display via the table.
So I would like to show a busy progress bar (on my LogInWidget) before the program finish loading the table.
I thought of using Qthread to accomplish it but since both tasks, displaying progress bar and creating DataTableWidget and setting as centralwidget is GUI tasks, how should i approach it?
You would have to connect your progress bar value to a signal from the DataTableWidget. But this in turn assumes that the DataTableWidget generates this signal many times while rendering it, which is not likely. Perhaps all you need is a way to show that the GUI is busy, like bar with a line on it that goes back and forth between the two ends of the bar. Then you don't need to exchange data between the the two widgets.
There is no straight forward way to do it. However, here is an idea:
As #schollii says, you need a signal to be emitted by DataTableWidget while it is rendering. Such a signal does not exist. And even if it did, it wouldn't be processed until the widget was rendered
However, if DataTableWidget has a model, you could override the data() method with your own which just calls the data() method of the base class and also updates a progress bar (though only update the progress bar when first rendering the table, not during subsequent calls to data()). As the view renders, the view will be calling the data() method many times. This way you get access to points in time during the rendering process.
Of course the progress bar will not redraw until control returns to the event loop (the rendering finishes), but you could probably work around that by calling QApplication.processEvents().
Note that this is quite hacky, in general bad practice, and completely destroys the model-view paradigm. I don't recommend doing it. But I can't think of anyway to achieve the same outcome. Perhaps you could just speed up the rendering of the DataTableWidget. For instance, QTableView.resizeColumnsToContents() is known to be slow. Are you calling that anywhere?
Related
I'm writing a unit test for a Qt application using the Squish framework. The squish scripting language is Python.
In order to make my test robust, I need to make sure that the GUI has completed an operation before checking the results.
In this GUI, I have a QTableView with an associated model. Certain operations will change the data in the model and the table will update. The update is sequenced internally by Qt.
My issue is that I need to know when the table has completed updating before I check to see whether it has the correct data.
I'm looking for ideas how to do this.
Squish not only views the QTableView GUI surface but will also access the underlying QAbstractItemModel. The data you see in your checks should therefore be live already.
But Qt GUIs are indeed full of asynchronous processing through timers, sometimes threads and signals. If you want to be notified on changes that are accompanied by a signal there's the installSignalHandler() function. If you want to wait for a particular state of to appear there's the waitFor() function. In the case of the table you may want to use
waitFor("mytable.model().rowCount() == 30")
for example.
I do understand there is way using Threads by emplying Qtimer and yes I do want it to update on a real time basis. I have experienced changing of these object Qlcd and Qlabel upon pushing button how ever i want it to update upon itself. Any help would be appreciated.
Since there was no answer from anyone I went in for digging and figured it out.
You need to add follwing code segment for repeated execution on a timely basis this helps the GUI update itself periodically for the stored variable data and update Qlable and QLCD widgets.
self.timer.timeout.connect(QtCore.SIGNAL(self.READ_DATA))
self.timer.start(51)
This upon trigger yield continus execturion as there is periodic signal generated.
Note: READ_DATA is the def i have declared in my program.
I'm writing some test functions for a form I made. There are a couple of QMessageBox that are invoked(one through QMessageBox.question method and one through the QMessageBox.information method. While my custom widget is not shown on screen, these two actually show up on screen.
I tried dismissing them by looping through widgets I get in QApplication.topLevelWidgets() and dismissing the right one, however, it seems my code only continues executing after I manually dismiss the MessageBox.
So my question is two-fold:
1) How do I keep the QMessageBox (or any widget really) from showing on screen during testing.
2) How can I programmatically accept/reject/dismiss this widget.
You can set up a timer to automatically accept the dialog. If the timeout is long, the dialog will still display for a while:
w = QtGui.QDialog(None)
t = QtCore.QTimer(None)
t.timeout.connect(w.accept)
t.start(1)
w.exec_()
For your specific case, if you don't want to touch the code being testes, you can have the timer run a function to accept all current modal widgets, as you were suggesting:
def accept_all():
for wid in app.topLevelWidgets():
if wid.__class__ == QtGui.QDialog: #or QMessageBox, etc:
wid.accept()
t = QtCore.QTimer(None)
t.timeout.connect(accept_all)
t.start(10)
I decided to use the mock module instead. It seemed better since the other solution would actually draw on screen, which is not optimal for testing.
If you have the same problem and would like to mock a question QMessageBox you can something like this:
#patch.object(path.QMessageBox, "question", return_value=QtGui.QMessageBox.Yes)
Would simulate a MessageBox in which the Yes button was clicked.
I think it makes sense with Qt testing (including PySide/PyQt) to mock your GUI interaction and do dedicated GUI testing separately as necessary.
For mocking GUI interaction, I'd use the mock library, as I myself do regularly. The drawback of this is that you have to depend on mock definitions, which may drift out of sync with respect to your production application. On the other hand, your tests will be speedier than involving the actual GUI.
For testing the GUI itself, I'd write a separate layer of tests using a GUI testing tool such as Froglogic Squish. It'll typically lead to more involved/slower tests, but you'll test your application directly, and not merely simulate the GUI layer. My approach in this regard is invest in such a tool if the budget allows, and run these tests as necessary keeping in mind they'll be relatively slow.
I'm developing a GUI with PyQt. The GUI has a qListWidget, a qTableWidget, and a plot implemented with Mayavi. The list refers to shapes that are plotted (cylinders and cones for example). When a shape is selected in the list, I want the shape's properties to be loaded into the table (from a dictionary variable) and the shape to be highlighted in the plot. I've got the Mayavi plotting working fine. Also, if the table is edited, I need the shape to be re-plotted, to reflect the new property value (like for a cylinder, if the radius is changed).
So, when a list item is selected -> update the table with the item's properties (from a dictionary variable), highlight the item on the plot
When the table is edited -> update the dictionary variable and re-plot the item
The Problem: when I select a list item and load data into the table, the qTableWidget ItemChanged signal fires every time a cell is updated, which triggers re-plotting the shape numerous times with incomplete data.
Is there a typical means of disabling the GUI event loop while the table is being programmatically updated? (I have experience with Excel VBA, in that context setting Application.EnableEvents=False will prevent triggering a WorksheetChange event every time a cell is programmatically updated.)
Should I have a "table update in progress" variable to prevent action from being taken while the table is being updated?
Is there a way to update the Table Widget all at once instead of item by item? (I'll admit I'm intentionally avoiding Model-View framework for the moment, hence the qListWIdget and qTableWidget).
Any suggestions?
I'm a first time poster, but a long time user of StackOverflow, so I just want to say thanks in advance for being such an awesome community!
blockSignals(bool) is intended for suppressing QObjects and their subclasses from emitting signals, thus preventing any other objects from receiving them in slots. But this is a QObject method. If you are specifically trying to prevent one object from emitting signals in response to changes that you are making, which might trigger calculations or some other expensive processing in a slot, then this is what you want.
But if your situation is that making repeated changes is causing expensive paint operations over and over (or other expensive events being generated on the widget), then you have the ability to disable updates with updatesEnabled(bool). A benefit of this method is that it recursively disables the children of the target widget, preventing them from being updated as well. So nothing in the hierarchy will receive updates until you enable again.
mainWidget.setUpdatesEnabled(False)
# do a bunch of operations that would trigger expensive events
# like repaints
mainWidget.setUpdatesEnabled(True)
Ultimately it depends on whether the source of your problem comes from triggering signals, or triggering widget events. Blocking the signals will still allow the widget to process its events, but just not notify any other listeners about it. updatesEnabled is a common way to wrap a number of list/table/tree updates. When it is enabled again afterwards, a single post update will be performed.
Signals can be temporarily blocked for any object that inherits QObject:
self.tableWidget.blockSignals(True)
# perform updates, etc
self.tableWidget.blockSignals(False)
If you disable the entire event loop, the app becomes unresponsive. And, even if the user doesn't notice, the OS might, and put up some kind of "hang" notification (like OS X's brightly-colored spinning beachball, which no user will ever miss).
You might want to disable repaints without disabling the event loop entirely. But even that's probably too drastic.
All you're really trying to do is make sure the table stops redrawing itself (without changing the way you've implemented your table view, which you admit isn't ideal, but you have reasons for).
So, just disable the ItemChanged updates. The easiest way to do this, in almost every case, is to call blockSignals(True) on the widget.
In the rare cases where this won't work (or when you're dealing with ancient code that's meant to be used in both Qt4-based and earlier projects), you can still get the handler(s) for the signal, stash them away, and remove them, then do your work, then restore the previous handler(s).
You could instead create a flag that the handlers can access, and change them so they do nothing if the flag is set. This is the traditional C way of doing things, but it's usually not what you want to do in Python.
I've a QTableView in a pyqt application. I continuously append rows to the underlying model. And what I want is the view to continuously scroll to the last, most recent row (is that behavior called "autoscrolling"?). But instead, the view does not scroll at all (automatically) and stays at its position.
Can I enable this autoscrolling behavior somehow or do I need to code something to achieve it?
Cheers,
Wolfgang
There is no default autoscrolling feature, but you can get the behavior relatively simple. Your model will emit rowsInserted when you insert/append rows. You can connect to that signal and call scrollToBottom on your view.
There is one problem though. View needs to adjust itself, because it won't put the item at the bottom immediately when rowsInserted fires. Calling scrollToBottom within a QTimer.singleShot solves this because QTimer will wait until there are no pending events (like update of the view).
Assuming the model is stored as self.model and view is self.view, this is how it'll look:
self.model.rowsInserted.connect(self.autoScroll)
and the autoScroll method:
def autoScroll(self):
QtCore.QTimer.singleShot(0, self.view.scrollToBottom)
Or if you prefer not having a seperate method for this:
self.model.rowsInserted.connect(lambda: QtCore.QTimer.singleShot(0, self.view.scrollToBottom))