I have a multi-threaded application written in Python in which one thread "takes care" of the GUI, and the other is the worker thread. However, the worker thread has two main functions (or so to say two main jobs), and I need to tell the run function which job exactly to do.
So what I had in mind was to create a run function in the worker thread which will take one parameter (save for "self). The parameter will either be "create" or upload. Without further ado, here's the somewhat-code that I have so far:
GUI.py
class GUI(QMainWindow):
def __init__(self, parent=None):
super, etc
self.worker = worker.Worker()
def create(self):
self.worker.start()
def upload(self):
self.worker.start()
Worker.py
class Worker(QThread):
def __init__(self, parent=None):
super, etc
def run(self):
self.create_data() # OR self.upload_data(), depends
So the question is, how can I tell worker.start() which function I want it to perform? I realize one could directly use worker.run() method, but I was told by the "Rapid GUI development with PyQT" never to call worker.run() directly, and always to use worker.start().
The start method of QThread doesn't accept arguments. However, you've inherited QThread so you're free to customize it at will. So, to implement what you want, just pass arguments into the constructor of Worker.
Here's your code sample slightly modified to show this in action:
class Worker(QThread):
def __init__(self, do_create_data=True, parent=None):
super(QThread, self).__init__()
self.do_create_data = create_data
def run(self):
if self.create_data:
self.create_data()
else:
self.upload_data(), depends
Eli Bendersky's answer is correct, however the order of arguments appears wrong.
If you call the Worker class like this:
The argument order that worked for me:
def __init__(self, parent=None, do_create_data=True):
The order shown in Eli Bendersky's answer produced this error message for me:
TypeError: QThread(QObject parent=None): argument 1 has unexpected type 'str'
Not sure why, but I'm sure someone can help explain.
Related
How do I create GUI classes for windows which have subwindows/classes that can access the main GUI's functions?
I have the below code which modifies the compiled .ui code from designer. What I want it to do is, when clicking the top-right "X", or using File -> Exit function, to close the window comprising the Window_SecondWindow class, and show the main window again--effectively calling the main window's show() from the subclass. I want to show only one window at a time.
When the code is run as-is, the Window_SecondWindow class hides, but immediately shows again, leading me to believe super is acting as self.
from PyQt5 import QtWidgets
from GUI import compiled_MainWindow
from GUI import compiled_SecondWindow
class Window_MainWindow(QtWidgets.QMainWindow):
def __init__(self):
super().__init__()
self.ui = compiled_MainWindow.Ui_MainWindow()
self.ui.setupUi(self)
self.ui.closeEvent = self.clicked_EXIT
# connect widgets
self.ui.Btn.clicked.connect(self.clicked_Btn)
self.ui.actionExit.triggered.connect(self.clicked_EXIT)
# add windows
self.SecondWindow = SecondWindow()
# more windows attached to main window
def clicked_Btn(self):
self.hide()
self.SecondWindow.show()
def clicked_EXIT(self):
self.close()
class Window_SecondWindow(Window_MainWindow):
def __init__(self):
QtWidgets.QMainWindow.__init__(self)
self.ui = compiled_SecondWindow.Ui_MainWindow()
self.ui.setupUi(self)
self.ui.closeEvent = self.clicked_EXIT
self.ui.actionExit.triggered.connect(self.clicked_EXIT)
def clicked_EXIT(self):
self.hide()
super().show()
Before answering your question, I'd like to address some important aspects.
First of all, never edit the generated code from pyuic to create your programs. They are intended to be used as imported modules, mostly as "resources": you import and integrate them into your code, but you should always leave them as they are. See the documentation on using Designer for more insight about this.
Be careful in overriding functions within the __init__: some functions are not "virtual" (thus, cannot be overwritten in such a way) and in some cases Qt always calls the base class function name anyway; just overwrite the method and call the base class implementation with super() if required. Also, closeEvent has the close event as a mandatory argument, and you have to add that to your overridden function, even if you don't use it (in the following examples I'm just using *args). That said, you should never use an overridden function as a slot that has a different argument, or viceversa.
Finally, you should not use capitalized names for attribute and variable names, as it is confusing and prone to errors (capitalization is mostly used for class names only, not their instancies).
Now, the answer
You are almost right, super() acts "as self", in the sense that it just calls the inherited show() method of the class against the instance. So, it calls the show method of Window_MainWindow, but since the instance is the second window, it's the same as doing Window_MainWindow.show(self), with self being the Window_SecondWindow instance; it is exactly as doing self.show().
There are two (and a half) possibilities.
The first, more obvious solution, is to give a reference of the main window instance to the second one:
class Window_MainWindow(QtWidgets.QMainWindow):
def __init__(self):
# ...
self.secondWindow = Window_SecondWindow()
self.secondWindow.mainWindow = self
class Window_SecondWindow(Window_MainWindow):
# ...
def clicked_EXIT(self, *args):
self.hide()
self.mainWindow.show()
Be aware that while, as #noras points out in the comment, you could set the main window as a parent in the init argument, but this only works as expected with QMainWindow and QDialog descendants; if the child widget is of any other kind, it will be shown inside the parent, not as a separate window.
The second (and more "Qt-wise correct") is to create a signal for the second class that is emitted when it's closed, and connect it in the main window so that it's shown again when that happens:
class Window_MainWindow(QtWidgets.QMainWindow):
def __init__(self):
# ...
self.secondWindow = Window_SecondWindow()
self.secondWindow.closed.connect(self.show)
class Window_SecondWindow(Window_MainWindow):
closed = QtCore.pyqtSignal()
def clicked_EXIT(self, *args):
self.hide()
self.closed.emit()
The second-and-a-half solution is to use an event filter:
class Window_MainWindow(QtWidgets.QMainWindow):
def __init__(self):
# ...
self.secondWindow = Window_SecondWindow()
self.secondWindow.installEventFilter(self)
def eventFilter(self, source, event):
if source == self.secondWindow and event.type() == QtCore.QEvent.Close:
self.show()
return super().eventFilter(source, event)
I am writing a class that has many functionalities(therefore methods), but I require this class to run inside a thread(class opens a subprocess). I want to use the common way of declaring thread based classes of,
class HiStackOverflow(threading.Thread):
# Somethings...
However, as I said, this class of mine has many pseudo-private, regular and static methods. And as I declare them, I want to avoid overriding some necessary threading.Thread method by mistake.
Well I can always check the directory of threading.Thread and see if there are any method names that overlap, however this seemed like a inappropriate way to handle this. It may be impractical as the method count increases.
My question is, is this kind of implementation feasible ? If not, how should I handle this ? Should I write some wrapper class as the Thread handler.
Thanks in advance.
If you're worried about namespace clashes between your class and threading.Thread, I would definitely suggest that you use composition rather than inheritance (or keep the two functionalities separate entirely). There shouldn't be significant overhead to just wrapping the couple threading methods that you need and then name clashes become a non-issue.
It also more cleanly will separate the functionality of your class from the functionality provided by threading. That's likely to be a win in the long run for understanding your code.
There isn't much benefit from inheriting from Thread. You could have a factory method that creates the thread or even have its __init__ do it.
import threading
import time
class MyClass:
def __init__(self):
self._thread = threading.Thread(target=self.run)
self._thread.start()
def run(self):
for i in range(5):
print('worker thread', i)
time.sleep(.5)
def join(self):
self._thread.join()
my_obj = MyClass()
for i in range(3):
print('main thread', i)
time.sleep(.5)
my_obj.join()
print('done')
There seem to be some ideas conflated in this phrase:
but I require this class to run inside a thread(class opens a subprocess)
Classes don't "run". You can start a new thread which executes some class method, or an instance method. That class doesn't have to inherit from Thread. It doesn't even need a reference to the running thread. You just start to execute some function in a new thread and you're done.
Subprocesses are unrelated to threads. You don't need one to do the other.
If you're worried about overriding something, check the documentation (https://docs.python.org/3/library/threading.html#thread-objects). Otherwise, if you want to keep the reference to the thread, you can always do:
class HiStackoverflow:
def run(self):
self.thread = Thread(target=self.entry_point)
self.thread.start()
def entry_point(self):
...
In this example, there's a threading subclass defined that I don't think does anything.
class ThreadClass(threading.Thread):
def run(self):
return
class otherClass(baseClass):
def __init__(self, foo):
bar
def main():
t = threadClass()
t.start()
oc = otherClass()
What does ThreadClass do?
If you go to the doc: https://docs.python.org/2/library/threading.html and look at the 16.2.1. Thread Objects section, I am pretty sure you will find the answer.
ThreadClass shows you the basic usage of writing your own class by deriving it from threading.Thread. It would make more sense if you try to do something in the run()
By writing your own class by deriving it from threading.Thread, you can have more flexibility for your own multi-thread tasks.
I have a somewhat strange problem. I'm coding a multithreaded app and am using SIGNALS to communicate the QThread's data to the GUI class data. Without further ado, here is a simplified code.
class GUI(uiMainWindow.MainWindow):
def __init__(self, parent=None):
super etc
self.thread = Thread()
self.connect(self.thread, SIGNAL("changeStatus(QString)"), self.setStatus, Qt.QueuedConnection)
def setStatus(self, status):
self.statusBar.setText(status)
class Thread(QThread):
def __init__(self, parent=None, create=True):
super etc
self.create = create
def run(self):
if self.create:
create_data()
if not self.create:
upload_data()
def create_data(self):
self.emit(SIGNAL("changeStatus(QString)"), "Changing the statusbar text")
#rest of the code
def upload_data(self):
self.emit(SIGNAL("changeStatus(QString)"), "Changing the statusbar text")
Pretty basic, right? However, here's the problem: the self.emit works only in create_data function, but not in upload_data (or for that matter, in any other function; I tried putting it in __init__ as well). I tried putting print "I got the status" + status in the setStatus function. Again, it works in the create_data() function, but not in the upload_data() function.
The differences between the two functions are relatively minor, and as far as I can tell, nothing is interfering with the self.emit function - in fact, in both cases, self.emit is only 4-5 lines "away" from the function definition.
This is really puzzling to me. Any help? Thanks in advance!
EDIT: again, as far as I can tell, the only difference between the two functions is in the run() - the first one is called if create parameter is True, and the second one if it is False.
I was right in my post. The difference between Thread() and Thread(create=False) was crucial. I had to define a new method (one was self.thread = Thread() and the other self.diff_thread = Thread(create=False)) and connect to different slots to make it work.
I'm having issues with a custom signal in a class I made.
Relevant code:
self.parse_triggered = QtCore.pyqtSignal()
def parseFile(self):
self.emit(self.parse_triggered)
Both of those belong to the class: RefreshWidget.
In its parent class I have:
self.refreshWidget.parse_triggered.connect(self.tabWidget.giveTabsData())
When I try to run the program, I get the error:
AttributeError: 'PyQt4.QtCore.pyqtSignal' object has no attribute 'connect'
Help?
Thanks in advance.
I had the same exact problem as you.
Try moving
self.parse_triggered = QtCore.pyqtSignal()
out of your constructor but inside your class declaration. So instead of it looking like this:
class Worker(QtCore.QThread):
def __init__(self, parent = None):
super(Worker, self).__init__(parent)
self.parse_triggered = QtCore.pyqtSignal()
It should look like this:
class Worker(QtCore.QThread):
parse_triggered = QtCore.pyqtSignal()
def __init__(self, parent = None):
super(Worker, self).__init__(parent)
This might not be at all what you are looking for, but it worked for me. I switched back to old-style signals anyways because I haven't found a way in new-style signals to have an undefined number or type of parameters.
You also get that error message if you fail to call super() or QObject.__init__() in your custom class.
A checklist for defining custom signals in a class in Qt in Python:
your class derives from QObject (directly or indirectly)
your class __init__ calls super() (or calls QObject.__init__() directly.)
your signal is defined as a class variable, not an instance variable
the signature (formal arguments) of your signal matches the signature of any slot that you will connect to the signal e.g. () or (int) or (str) or ((int,), (str,))
I have recently started working with PySide (Nokia's own version of PyQt), and saw the exact same behaviour (and solution) with custom new-style signals. My biggest concern with the solution was that using a class variable to hold the signal would mess things up when I have multiple instances of that class (QThreads in my case).
From what I could see, QtCore.QObject.__init__(self) finds the Signal variable in the class and creates a copy of that Signal for the instance. I have no idea what QObject.__init__() does, but the resulting Signal does proper connect(), disconnect() and emit() methods (and also a __getitem__() method), whereas the class Signal or standalone Signal variables created outside of a QObject-derived class do not have these methods and can't be used properly.
To use the signal/slot system you need to have a QObject inherited class.
Here is a simple example:
from PySide import QtCore
class LivingBeing(QtCore.QObject):
bornSignal = QtCore.Signal() # initialise our signal
def __init__(self,name):
QtCore.QObject.__init__(self) # initialisation required for object inheritance
self.bornSignal.connect(self.helloWorld) # connect the born signal to the helloworld function
self.name = name #
self.alive = False
def summonFromClay(self):
self.alive = True
self.bornSignal.emit() # emit the signal
def helloWorld(self):
print "Hello World !, my name is %s, this place is so great !" % self.name
# now try the little piece of code
if __name__ == '__main__':
firstHuman = LivingBeing('Adam')
firstHuman.summonFromClay()
I had the same problem.
I forgot that if a class uses Signals, then it must inherit from QObject. I was doing some re-factoring and did not pay attention to this.
Why do you connect directly to the signal, while you can do
self.connect(widget, SIGNAL('parse_triggered()'), listener.listening_method)?
where self is, for example, the form itself, and may be the same as listener