I would like to change behavior of Key_Delete for QTableWidget, but because of using Designer I don't want to make any changes in py file with form. So instead of reimplementing QTableWidget like it is this answer: How to implement MousePressEvent for a Qt-Designer Widget in PyQt I do something like this:
class MyForm(QtGui.QMainWindow):
def __init__(self, parent=None):
QtGui.QWidget.__init__(self, parent)
self.ui = Ui_MainWindow()
self.ui.setupUi(self)
self.ui.tableWidget.__class__.keyPressEvent = self.test
def test(self,event):
if event.key() == Qt.Key_Delete:
print "test"
return QTableWidget.keyPressEvent(self, event)
The problem is that I don't know how to keep original behavior of other keys than Qt.Key_Delete.
I have already changed last line like this:
return QtGui.QTableWidget.keyPressEvent(self, event)
return QtGui.QTableWidget.event(self, event)
but it doesn't work.
First: "but it doesn't work" is usually not descriptive enough. What behavior did you expect? What was the behavior you saw instead? Were there any error messages?
I can easily see a few mistakes in here, though.
You're overriding the method QTableWidget.keyPressEvent, which expects 2 arguments: (QTableWidget instance, event). But in the code you show above, the function you are using to override it only takes 1 argument (the first argument, 'self', does not count since it is automatically supplied).
Since you have set QTableWidget.keyPressEvent = self.test, and you are also trying to call this function from within self.test(), you have created an infinitely recursive function.
When you call QTableWidget.keyPressEvent, the first argument you have passed in (self) is a QMainWindow object. However as I mentioned above, this function expects a QTableWidget as its first argument.
Since you are overriding this method at the class level, ALL QTableWidgets will be forced to use the same keyPressEvent function (this would be very problematic). Instead, you should override just your specific widget's method: self.ui.tableWidget.keyPressEvent = self.test (also note that the signature for tableWidget.keyPressEvent is different from QTableWidget.keyPressEvent)
Example:
from PyQt4 import QtCore, QtGui
app = QtGui.QApplication([])
win = QtGui.QMainWindow()
win.show()
table = QtGui.QTableWidget()
win.setCentralWidget(table)
def test(event):
if event.key() == QtCore.Qt.Key_Delete:
print "delete"
return QtGui.QTableWidget.keyPressEvent(table, event)
table.keyPressEvent = test
Finally, another (possibly cleaner) approach would be to create a subclass of QTableWdget and, within Designer, 'promote' the table widget to your new class.
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)
The title says most of it. I have to be something dumb here but for some reason anytime I try to override the edit function of a QTreeView when I right click on the Treeview I get a Maximum recursion depth error.
This is specifically when I try to call the super's edit function. Here is an example of the problem. What am I messing up here?
from PyQt5 import QtWidgets, QtGui, QtCore
class EditTreeView(QtWidgets.QTreeView):
editingRequested = QtCore.pyqtSignal(QtCore.QModelIndex)
def __init__(self, parent=None):
super(EditTreeView, self).__init__(parent)
def edit(self, index, QAbstractItemView_EditTrigger=None, QEvent=None):
super(EditTreeView, self).edit(index)
class testTreeview(QtWidgets.QWidget):
def __init__(self, parent=None):
super(testTreeview, self).__init__(parent)
self.mainTree = EditTreeView()
self.lo = QtWidgets.QVBoxLayout()
self.lo.addWidget(self.mainTree)
self.setLayout(self.lo)
self.model = QtGui.QStandardItemModel()
self.mainTree.setModel(self.model)
def populate(self):
row = [QtGui.QStandardItem('teststuff'), ]
root = self.model.invisibleRootItem()
root.appendRow(row)
if __name__ == "__main__":
from PyQt5 import QtCore, QtGui, QtWidgets
app = QtWidgets.QApplication([])
volume = testTreeview()
volume.show()
app.exec_()
Explanation:
QTreeView inherits from QAbstractItemView, and if you review the methods of that class, you can see that there are 2 methods with the same name:
bool QAbstractItemView::edit(const QModelIndex &index,
QAbstractItemView::EditTrigger trigger, QEvent *event)
Starts editing the item at index, creating an editor if necessary, and
returns true if the view's State is now EditingState; otherwise
returns false.
The action that caused the editing process is described by trigger,
and the associated event is specified by event.
Editing can be forced by specifying the trigger to be
QAbstractItemView::AllEditTriggers.
void QAbstractItemView::edit(const QModelIndex &index)
Starts editing the item corresponding to the given index if it is
editable.
Note that this function does not change the current index. Since the
current index defines the next and previous items to edit, users may
find that keyboard navigation does not work as expected. To provide
consistent navigation behavior, call setCurrentIndex() before this
function with the same model index.
It is observed that the first method is more general than the second one, so it gives us a suspicion that the second one will use the first one and indeed this happens if the source code is reviewed:
void QAbstractItemView::edit(const QModelIndex & index)
{
Q_D(QAbstractItemView);
if (Q_UNLIKELY(!d->isIndexIsValid(index)))
qWarning("edit: index was invalid");
if (Q_UNLIKELY(!edit(index, AllEditTriggers, 0)))
qWarning("edit: editing failed");
}
So in your case clearly explain the error: you are overriding the first method and invoking the second, but the second uses the first according to the source code, and returned to the infinite cycle.
Solution
The solution is to use the super of the same method with all the parameters:
class EditTreeView(QtWidgets.QTreeView):
editingRequested = QtCore.pyqtSignal(QtCore.QModelIndex)
def edit(self, index, trigger, event):
self.editingRequested.emit(index)
return super(EditTreeView, self).edit(index, trigger, event)
But keep in mind that the override is about the first method, in C++ it is allowed to have methods with the same name but in python if there are several methods with the same name the last one will erase the previous ones.
When an item (spinBox, LineEdit etc) changes its value in GUI (via designer) I set a certain button's enable status. For example:
self.ui.lineEdit_1.textChanged.connect(self.pushButton_status)
self.ui.checkBox_1.stateChanged.connect(self.pushButton_status)
self.ui.spinBox_1.valueChanged.connect(self.pushButton_status)
self.ui.spinBox_2.valueChanged.connect(self.pushButton_status)
self.ui.spinBox_3.valueChanged.connect(self.pushButton_status)
self.ui.spinBox_4.valueChanged.connect(self.pushButton_status)
This works fine. Though there are lots of lines here (and even more in the actual code). I have all of these items inside a frame (QFrame). So I was wondering if it is possible to do something like:
self.ui.frame_1.childValueChanged.connect(self.pushButton_status)
which could perhaps stand for all the items inside of it. Is there any way within this logic that could do what I am looking for? If so.. how?
There is no direct way to do what you want, but there is a maintainable way to do it, in this case you just have to filter the type of widget and indicate which signal you will use by adding more options to the function, in your case:
def connectToChildrens(parentWidget, slot):
# get all the children that are widget
for children in parentWidget.findChildren(QtWidgets.QWidget):
# filter if the class that belongs to the object is QLineEdit
if isinstance(children, QtWidgets.QLineEdit):
# Connect the signal with the default slot.
children.textChanged.connect(slot)
elif isinstance(children, QtWidgets.QCheckBox):
children.stateChanged.connect(slot)
elif isinstance(children, QtWidgets.QSpinBox):
children.valueChanged.connect(slot)
And then you use it in the following way:
class MyDialog(QDialog):
def __init__(self, parent=None):
super(MyDialog, self).__init__(parent)
self.ui = Ui_MyDialog()
self.ui.setupUi(self)
connectToChildrens(self.ui.frame_1, self.pushButton_status)
I have a QPushButton, called 'StartButton' in my MainWindow. The Button's name, position and everything else is defined in the Qt Designer, so I don't define anything in my programm.
I want to replace self.StartButton.clicked.... with something like QtGui.MyMainWindow.StartButton.clicked....
Is that possible at all and what should I write instead of self?
class MainWindow(QtGui.QMainWindow, QtGui.QFileDialog):
def __init__(self, parent=None):
super(MainWindow, self).__init__(parent)
uic.loadUi('MyMainWindow.ui', self)
self.StartButton.clicked.connect(MainWindow.do_something())
Your line should read:
self.StartButton.clicked.connect(self.do_something)
I made two changes:
First, I removed the parentheses. You were calling do_something, rather than passing it as an argument to connect.
The second change is replacing MainWindow with self. I realize that you want to avoid this, but MainWindow is merely the class. self is the instance of MainWindow you are trying to connect to.
Note: you are also inheriting from two different widgets (QMainWindow and QFileDialog), which leads to undefined behavior in Qt. Unfortunately, you have to pick one or the other or things will break.
In PyQt, you can use QtCore.pyqtSignal() to create custom signals.
I tried making my own implementation of the Observer pattern in place of pyqtSignal to circumvent some of its limitations (e.g. no dynamic creation).
It works for the most part, with at least one difference.
Here is my implementation so far
class Signal:
def __init__(self):
self.__subscribers = []
def emit(self, *args, **kwargs):
for subs in self.__subscribers:
subs(*args, **kwargs)
def connect(self, func):
self.__subscribers.append(func)
def disconnect(self, func):
try:
self.__subscribers.remove(func)
except ValueError:
print('Warning: function %s not removed from signal %s'%(func,self))
The one thing noticed was a difference in how QObject.sender() works.
I generally stay clear of sender(), but if it works differently then so may other things.
With regular pyqtSignal signals, the sender is always the widget closest in a chain of signals.
In the example at the bottom, you'll see two objects, ObjectA and ObjectB. ObjectA forwards signals from ObjectB and is finally received by Window.
With pyqtSignal, the object received by sender() is ObjectA, which is the one forwarding the signal from ObjectB.
With the Signal class above, the object received is instead ObjectB, the first object in the chain.
Why is this?
Full example
# Using PyQt5 here although the same occurs with PyQt4
from PyQt5.QtCore import *
from PyQt5.QtGui import *
from PyQt5.QtWidgets import *
class Window(QWidget):
def __init__(self, parent=None):
super(Window, self).__init__(parent)
object_a = ObjectA(self)
object_a.signal.connect(self.listen)
layout = QBoxLayout(QBoxLayout.TopToBottom, self)
layout.addWidget(object_a)
def listen(self):
print(self.sender().__class__.__name__)
class ObjectA(QWidget):
signal = Signal()
# signal = pyqtSignal()
def __init__(self, parent=None):
super(ObjectA, self).__init__(parent)
object_b = ObjectB()
object_b.signal.connect(self.signal.emit)
layout = QBoxLayout(QBoxLayout.TopToBottom, self)
layout.addWidget(object_b)
class ObjectB(QPushButton):
signal = Signal()
# signal = pyqtSignal()
def __init__(self, parent=None):
super(ObjectB, self).__init__('Push me', parent)
self.pressed.connect(self.signal.emit)
if __name__ == '__main__':
import sys
app = QApplication([])
win = Window()
win.show()
sys.exit(app.exec_())
More reference
Edit:
Apologies, I should have provided a use-case.
Here are some of the limitations of using pyqtSignals:
pyqtSignal:
..only works with class attributes
..cannot be used in an already instantiated class
..must be pre-specified with the data-types you wish to emit
..produces signals that does not support keyword arguments and
..produces signals that cannot be modified after instantiation
Thus my main concern is using it together with baseclasses.
Consider the following.
6 different widgets of a list-type container widget share the same interface, but look and behave slightly different. A baseclass provides the basic variables and methods, along with signals.
Using pyqtSignal, you would have to first inherit your baseclass from at least QObject or QWidget.
The problem is neither of these can be use in as mix-ins or in multiple inheritance, if for instance one of the widgets also inherits from QPushButton.
class PinkListItem(QPushButton, Baseclass)
Using the Signal class above, you could instead make baseclasses without any previously inherited classes (or just object) and then use them as mix-ins to any derived subclasses.
Careful not to make the question about whether or not multiple inheritance or mix-ins are good, or of other ways to achieve the same thing. I'd love your feedback on that as well, but perhaps this isn't the place.
I would be much more interested in adding bits to the Signal class to make it work similar to what pyqtSignal produces.
Edit 2:
Just noticed a down-vote, so here comes some more use cases.
Key-word arguments when emitting.
signal.emit(5)
Could instead be written as
signal.emit(velocity=5)
Use with a Builder or with any sort of dependency injection
def create(type):
w = MyWidget()
w.my_signal = Signal()
return w
Looser coupling
I'm using both PyQt4 and PyQt5. With the Signal class above, I could produce baseclasses for both without having it depend on either.
You can do this with a metaclass that inherits from pyqtWrapperType. Inside __new__, call pyqtSignal() as needed and set the attributes on the result class.