[PyQt] Bug in QAction?
Hi, I'm trying PyQt-x11-gpl-snapshot-4.8.4-8641ecc135b3 on a debian testing box with Python2.7 and virtualenv-1.5.1. Running the attached script raises the following error: (venv2.7)vmas@rachael:/tmp$ Traceback (most recent call last): File "test_qaction.py", line 9, in shortcut=QtGui.QKeySequence.New) TypeError: keyword arguments are not supported As far as I know the support of keyword arguments has not been dropped so I suppose it is a bug. Am I right or am I missing something? Vicent :: Share what you know, learn what you don't # -*- coding: utf-8 -*- import sys from PyQt4 import QtGui if __name__ == '__main__': app = QtGui.QApplication(sys.argv) action = QtGui.QAction( 'Sample action', None, shortcut=QtGui.QKeySequence.New) app.exec_() signature.asc Description: This is a digitally signed message part. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] signal/slot vs Qt.UniqueConnection ?
Hi,
I'm quite sure I'm missing something fundamental here but I can't get
QObject.connect to work as expected when using Qt.UniqueConnection as a
connection type.
I attached some code that demonstrates my problem. I would expect that
the slot is called only once.
versions:
PyQt4: 4.8.3
Qt: 4.7.0
sip: 4.12.1
python: 2.6.5
thx
Zoli
from PyQt4.QtCore import *
class A(QObject):
signal = pyqtSignal()
def __init__(self, parent=None):
super(A, self).__init__(parent)
def connectNotify(self, signal):
print 'connectNotify', signal
#@pyqtSlot()
def slot():
print 'slot called'
a = A()
# print QObject.connect(a, SIGNAL('signal()'), slot, Qt.UniqueConnection)
# print QObject.connect(a, SIGNAL('signal()'), slot, Qt.UniqueConnection)
# a.emit(SIGNAL('signal()'))
print a.signal.connect(slot, Qt.UniqueConnection)
print a.signal.connect(slot, Qt.UniqueConnection)
a.signal.emit()___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Position widgets over widgets
Hi,
I have attached a simple example where a widget sets up two labels. One
which is added to the layout of the widget, and one which is not.
In the paintEvent() of the parent widget I instead position the
non-layout label using setGeometry to make it appear in the center of
the parent widget.
However, the label positioned by this approach is always obscured by the
widget which was added to the layout. I want it to appear as visible,
i.e. visible on top of the parent widget.
Any clues?
Best regards,
Mads
import sys
from PyQt4 import QtGui
class Widget(QtGui.QWidget):
def __init__(self, parent=None):
QtGui.QWidget.__init__(self)
self._label2 = QtGui.QLabel('XXX', self)
self._label2.show()
self._label1 = QtGui.QLabel()
self._label1.setAutoFillBackground(True)
palette = QtGui.QPalette()
palette.setColor(self._label1.backgroundRole(), QtGui.QColor('blue'))
self._label1.setPalette(palette)
layout = QtGui.QVBoxLayout()
self.setLayout(layout)
layout.addWidget(self._label1)
def paintEvent(self, event):
w = self._label2.width()
h = self._label2.height()
x = (self.rect().width() - w)/2.0
y = (self.rect().height() - h)/2.0
self._label2.setGeometry(x,y,w,h)
if __name__ == "__main__":
app = QtGui.QApplication(sys.argv)
widget = Widget()
widget.show()
sys.exit(app.exec_())
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Position widgets over widgets
On Thursday 07 April 2011, 14:58:30 Mads Ipsen wrote: > Hi, > > I have attached a simple example where a widget sets up two labels. > One which is added to the layout of the widget, and one which is not. > > In the paintEvent() of the parent widget I instead position the > non-layout label using setGeometry to make it appear in the center of > the parent widget. > > However, the label positioned by this approach is always obscured by > the widget which was added to the layout. I want it to appear as > visible, i.e. visible on top of the parent widget. Create _label2 after _label1, but this is a questionable approach. Why can't you use something like QStackedLayout? Pete ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Position widgets over widgets
Hi,
I tried that, but is does not seem to work. The 'XXX' is still hidden by
the widget in the layout.
What I eventually would like to achieve is to add a QPushButton in, say,
the upper left corner of the parent widget.
I have attached a similar example, this time with a QPushButton. This
QPushButton is rendered useless (i.e.) you cannot press it.
I thought solving this problem would be a walk in the park. Any clues?
Best regards,
Mads
On 2011-04-07 15:19, Hans-Peter Jansen wrote:
On Thursday 07 April 2011, 14:58:30 Mads Ipsen wrote:
Hi,
I have attached a simple example where a widget sets up two labels.
One which is added to the layout of the widget, and one which is not.
In the paintEvent() of the parent widget I instead position the
non-layout label using setGeometry to make it appear in the center of
the parent widget.
However, the label positioned by this approach is always obscured by
the widget which was added to the layout. I want it to appear as
visible, i.e. visible on top of the parent widget.
Create _label2 after _label1, but this is a questionable approach.
Why can't you use something like QStackedLayout?
Pete
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
--
+-+
| Mads Ipsen |
+--+--+
| Florsgade 7, 4. th | |
| DK-2200 København N | phone: +45-29716388 |
| Denmark | email: mads.ip...@gmail.com |
+--+--+
import sys
from PyQt4 import QtGui
class Widget(QtGui.QWidget):
def __init__(self, parent=None):
QtGui.QWidget.__init__(self)
self._label = QtGui.QLabel('A Label')
self._button = QtGui.QPushButton('&Push Me', self)
layout = QtGui.QVBoxLayout()
self.setLayout(layout)
layout.addWidget(self._label)
def paintEvent(self, event):
w = self._button.width()
h = self._button.height()
x = (self.rect().width() - w)/2.0
y = (self.rect().height() - h)/2.0
self._button.setGeometry(x,y,w,h)
if __name__ == "__main__":
app = QtGui.QApplication(sys.argv)
widget = Widget()
widget.show()
sys.exit(app.exec_())
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] signal/slot vs Qt.UniqueConnection ?
On Thursday 07 April 2011, 12:49:43 Zoltan Szalai wrote: > Hi, > > I'm quite sure I'm missing something fundamental here but I can't get > QObject.connect to work as expected when using Qt.UniqueConnection as > a connection type. > I attached some code that demonstrates my problem. I would expect > that the slot is called only once. Hmm, it seems to depend on the type of slot argument, and is probably something, that Phil hasn't expected. It seems to work this way: from PyQt4.QtCore import * class A(QObject): signal = pyqtSignal() def __init__(self, parent=None): super(A, self).__init__(parent) def connectNotify(self, signal): print 'connectNotify:', signal @pyqtSlot() def slot(self): print 'slot called' app = QCoreApplication([]) a = A() print "1:", a.signal.connect(a.slot, Qt.UniqueConnection) print "2:", a.signal.connect(a.slot, Qt.UniqueConnection) a.signal.emit() Now, an exception is thrown in the second attempt to connect: Traceback (most recent call last): File "uniqueconnection_test.py", line 19, in print "2:", a.signal.connect(a.slot, Qt.UniqueConnection) TypeError: connect() failed between A.signal[] and slot() Another strange effect is, that in your case with a slot as a function something connects to the destroyed(QObject*) signal, but not in mine. Pete ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Position widgets over widgets
On Thursday 07 April 2011, 15:36:47 Mads Ipsen wrote:
> Hi,
>
> I tried that, but is does not seem to work. The 'XXX' is still hidden
> by the widget in the layout.
>
> What I eventually would like to achieve is to add a QPushButton in,
> say, the upper left corner of the parent widget.
>
> I have attached a similar example, this time with a QPushButton. This
> QPushButton is rendered useless (i.e.) you cannot press it.
>
> I thought solving this problem would be a walk in the park. Any
> clues?
import sys
from PyQt4 import QtGui
class Widget(QtGui.QWidget):
def __init__(self, parent=None):
QtGui.QWidget.__init__(self)
self._label = QtGui.QLabel('A Label')
layout = QtGui.QVBoxLayout()
self.setLayout(layout)
layout.addWidget(self._label)
self._button = QtGui.QPushButton('&Push Me', self)
def paintEvent(self, event):
w = self._button.width()
h = self._button.height()
x = (self.rect().width() - w)/2.0
y = (self.rect().height() - h)/2.0
self._button.setGeometry(x,y,w,h)
if __name__ == "__main__":
app = QtGui.QApplication(sys.argv)
widget = Widget()
widget.show()
sys.exit(app.exec_())
I will abjure any relation to this code..
Pete
> Best regards,
>
> Mads
>
> On 2011-04-07 15:19, Hans-Peter Jansen wrote:
> > On Thursday 07 April 2011, 14:58:30 Mads Ipsen wrote:
> >> Hi,
> >>
> >> I have attached a simple example where a widget sets up two
> >> labels. One which is added to the layout of the widget, and one
> >> which is not.
> >>
> >> In the paintEvent() of the parent widget I instead position the
> >> non-layout label using setGeometry to make it appear in the center
> >> of the parent widget.
> >>
> >> However, the label positioned by this approach is always obscured
> >> by the widget which was added to the layout. I want it to appear
> >> as visible, i.e. visible on top of the parent widget.
> >
> > Create _label2 after _label1, but this is a questionable approach.
> >
> > Why can't you use something like QStackedLayout?
> >
> > Pete
> > ___
> > PyQt mailing listPyQt@riverbankcomputing.com
> > http://www.riverbankcomputing.com/mailman/listinfo/pyqt
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Bug in QAction?
On Thursday 07 April 2011, 12:12:48 Vicent Mas wrote: > Hi, > > I'm trying PyQt-x11-gpl-snapshot-4.8.4-8641ecc135b3 on a debian > testing box with Python2.7 and virtualenv-1.5.1. Running the attached > script raises the following error: > > (venv2.7)vmas@rachael:/tmp$ Traceback (most recent call last): > File "test_qaction.py", line 9, in > shortcut=QtGui.QKeySequence.New) > TypeError: keyword arguments are not supported > > As far as I know the support of keyword arguments has not been > dropped so I suppose it is a bug. Am I right or am I missing > something? Did this worked in earlier versions? I don't use keyword arguments much, but according to the builtin help, QAction simply didn't define any (and neither provides the signature a shortcut argument): >>> help(QtGui.QAction) class QAction(PyQt4.QtCore.QObject) | QAction(QObject) | QAction(QString, QObject) | QAction(QIcon, QString, QObject) in contrary to: >>> help(QtGui.QWidget) class QWidget(PyQt4.QtCore.QObject, QPaintDevice) | QWidget(QWidget parent=None, Qt.WindowFlags flags=0) Pete ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Bug in QAction?
On 2011-04-07 "Hans-Peter Jansen" said: > On Thursday 07 April 2011, 12:12:48 Vicent Mas wrote: > > Hi, > > > > I'm trying PyQt-x11-gpl-snapshot-4.8.4-8641ecc135b3 on a debian > > testing box with Python2.7 and virtualenv-1.5.1. Running the attached > > script raises the following error: > > > > (venv2.7)vmas@rachael:/tmp$ Traceback (most recent call last): > > File "test_qaction.py", line 9, in > > > > shortcut=QtGui.QKeySequence.New) > > > > TypeError: keyword arguments are not supported > > > > As far as I know the support of keyword arguments has not been > > dropped so I suppose it is a bug. Am I right or am I missing > > something? > > Did this worked in earlier versions? I don't use keyword arguments much, > but according to the builtin help, QAction simply didn't define any > > (and neither provides the signature a shortcut argument): > >>> help(QtGui.QAction) > > class QAction(PyQt4.QtCore.QObject) > > | QAction(QObject) > | QAction(QString, QObject) > | QAction(QIcon, QString, QObject) > > in contrary to: > >>> help(QtGui.QWidget) > > class QWidget(PyQt4.QtCore.QObject, QPaintDevice) > > | QWidget(QWidget parent=None, Qt.WindowFlags flags=0) > > Pete > ___ > PyQt mailing listPyQt@riverbankcomputing.com > http://www.riverbankcomputing.com/mailman/listinfo/pyqt Hi, It works fine with PyQt4.8.3. The only documentation I know regarding this is http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/keyword_arguments.html although it is not specific to QAction. Vicent :: Share what you know, learn what you don't signature.asc Description: This is a digitally signed message part. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] why do closeEvent and destroyed slot not get called on accepting PyQt4 QDialog?
I truly believe you are approaching this from the wrong angle. If you need to know when your QDialog is going away, you override closeEvent and do your cleanup from there. However, looking through the docs, it does not appear that destroy is actually a signal. It's called from the QWidget dtor, so it makes sense that if you call destroy(), you get the runtime error because you are deleting the C++ object before the Python object. Do not call destroy yourself - call self.close and override closeEvent. From there you can accept or reject closing the dialog, and do any cleanup prior to your dialog being destroyed. >From the Qt Docs: void QWidget::destroy ( bool destroyWindow = true, bool destroySubWindows = true ) [protected] Frees up window system resources. Destroys the widget window if destroyWindow is true. destroy() calls itself recursively for all the child widgets, passing destroySubWindows for the destroyWindow parameter. To have more control over destruction of subwidgets, destroy subwidgets selectively first. This function is usually called from the QWidget destructor. On Thu, Apr 7, 2011 at 3:04 AM, Rui DaCosta wrote: > I know it can close it manually, the problem is that this is a > simplification of a problem I had, in which we were expecting the QDialog to > close as per the docs, but it did not. > The *real* problem we are facing, is a bit further down the line, where we > are getting the "RuntimeError: underlying C/C++ object has been deleted" > but we never receive a destroyed signal. > The only reason I need this signal or event is to do some teardown code for > some callbacks to avoid getting this c++ error elsewhere. > > -- > *From:* Demetrius Cassidy > *To:* RuiDC > *Sent:* Thu, 7 April, 2011 0:39:33 > *Subject:* Re: [PyQt] why do closeEvent and destroyed slot not get called > on accepting PyQt4 QDialog? > > If you want to close, just call self.close. It's a slot, so you can map it > to any signal. Also not sure why you want to know when your widget is > destroyed? Let Python take care of it, you should not need to call > sip.delete yourself. closeEvent is there if you need to know _when_ your app > was requested to close. If you want to allow or reject closing the app, you > need to use the QEvent object which gets passed to that function. > > On Wed, Apr 6, 2011 at 5:27 PM, RuiDC wrote: > >> >> The question & code are here: >> >> http://stackoverflow.com/questions/5570402/why-do-closeevent-and-destroyed-slot-not-get-called-on-accepting-pyqt4-qdialog >> >> but hopefully someone here can give me an answer on: >> 1. how to get the closeEvent to fire from accepting (or do I have to do a >> self.close()?) >> 2. how to get the destroyed message to print (or do I have to go through >> sip.delete(my_widget)?) >> 3. why, if I comment out the del my_widget, and uncomment the >> my_widget.destroy() I get a: >> RuntimeError: underlying C/C++ object has been deleted >> on the destroy() without the print! i.e. how is it that it can be >> destroyed >> but not raise the signal? >> >> Thanks in advance, >> R >> -- >> View this message in context: >> http://old.nabble.com/why-do-closeEvent-and-destroyed-slot-not-get-called-on-accepting-PyQt4-QDialog--tp31336229p31336229.html >> Sent from the PyQt mailing list archive at Nabble.com. >> >> ___ >> PyQt mailing listPyQt@riverbankcomputing.com >> http://www.riverbankcomputing.com/mailman/listinfo/pyqt >> > > ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] why do closeEvent and destroyed slot not get called on accepting PyQt4 QDialog?
Sorry found destroyed() - that's what happens when you reply to emails before you have morning coffee. Anyway I'm not sure why destroyed() is never fired. I tried your code and even modified it a bit to use the new style slots and signals but it's not being fired. Either way, I think the other points I raised in my last email are still valid. IMHO using destroyed() in python is the wrong approach. On Thu, Apr 7, 2011 at 11:02 AM, Demetrius Cassidy wrote: > I truly believe you are approaching this from the wrong angle. If you need > to know when your QDialog is going away, you override closeEvent and do your > cleanup from there. > > However, looking through the docs, it does not appear that destroy is > actually a signal. It's called from the QWidget dtor, so it makes sense that > if you call destroy(), you get the runtime error because you are deleting > the C++ object before the Python object. Do not call destroy yourself - call > self.close and override closeEvent. From there you can accept or reject > closing the dialog, and do any cleanup prior to your dialog being destroyed. > > From the Qt Docs: > > void QWidget::destroy ( bool destroyWindow = true, bool destroySubWindows = > true ) [protected] > > Frees up window system resources. Destroys the widget window if > destroyWindow is true. > > destroy() calls itself recursively for all the child widgets, passing > destroySubWindows for the destroyWindow parameter. To have more control over > destruction of subwidgets, destroy subwidgets selectively first. > > This function is usually called from the QWidget destructor. > > On Thu, Apr 7, 2011 at 3:04 AM, Rui DaCosta wrote: > >> I know it can close it manually, the problem is that this is a >> simplification of a problem I had, in which we were expecting the QDialog to >> close as per the docs, but it did not. >> The *real* problem we are facing, is a bit further down the line, where we >> are getting the "RuntimeError: underlying C/C++ object has been deleted" >> but we never receive a destroyed signal. >> The only reason I need this signal or event is to do some teardown code >> for some callbacks to avoid getting this c++ error elsewhere. >> >> -- >> *From:* Demetrius Cassidy >> *To:* RuiDC >> *Sent:* Thu, 7 April, 2011 0:39:33 >> *Subject:* Re: [PyQt] why do closeEvent and destroyed slot not get called >> on accepting PyQt4 QDialog? >> >> If you want to close, just call self.close. It's a slot, so you can map it >> to any signal. Also not sure why you want to know when your widget is >> destroyed? Let Python take care of it, you should not need to call >> sip.delete yourself. closeEvent is there if you need to know _when_ your app >> was requested to close. If you want to allow or reject closing the app, you >> need to use the QEvent object which gets passed to that function. >> >> On Wed, Apr 6, 2011 at 5:27 PM, RuiDC wrote: >> >>> >>> The question & code are here: >>> >>> http://stackoverflow.com/questions/5570402/why-do-closeevent-and-destroyed-slot-not-get-called-on-accepting-pyqt4-qdialog >>> >>> but hopefully someone here can give me an answer on: >>> 1. how to get the closeEvent to fire from accepting (or do I have to do a >>> self.close()?) >>> 2. how to get the destroyed message to print (or do I have to go through >>> sip.delete(my_widget)?) >>> 3. why, if I comment out the del my_widget, and uncomment the >>> my_widget.destroy() I get a: >>> RuntimeError: underlying C/C++ object has been deleted >>> on the destroy() without the print! i.e. how is it that it can be >>> destroyed >>> but not raise the signal? >>> >>> Thanks in advance, >>> R >>> -- >>> View this message in context: >>> http://old.nabble.com/why-do-closeEvent-and-destroyed-slot-not-get-called-on-accepting-PyQt4-QDialog--tp31336229p31336229.html >>> Sent from the PyQt mailing list archive at Nabble.com. >>> >>> ___ >>> PyQt mailing listPyQt@riverbankcomputing.com >>> http://www.riverbankcomputing.com/mailman/listinfo/pyqt >>> >> >> > ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] why do closeEvent and destroyed slot not get called on accepting PyQt4 QDialog?
Firstly thanks again for your reply, In the original code, from where this simplification is based, I have cleanup code on both closeEvent and destroyed, but... that's just the problem, the closeEvent isn't getting fired (unless I manually call close) - except when the window is closed from the close box. I was expecting that from the docs for done(), I would not have to on done(), ie. is this a bug? or are the docs incorrect? And separately, destroyed is a signal according to the docs http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/qobject.html#destroyed but I cannot get it to fire for QDialog, no matter what I do, including manually calling destroy(). The object appears deleted when inspected with sip.isdeleted, even before the destroy() - so if that is the case, why does it not raise a destroyed signal? From: Demetrius Cassidy To: Rui DaCosta Cc: pyqt@riverbankcomputing.com Sent: Thu, 7 April, 2011 17:02:04 Subject: Re: [PyQt] why do closeEvent and destroyed slot not get called on accepting PyQt4 QDialog? I truly believe you are approaching this from the wrong angle. If you need to know when your QDialog is going away, you override closeEvent and do your cleanup from there. However, looking through the docs, it does not appear that destroy is actually a signal. It's called from the QWidget dtor, so it makes sense that if you call destroy(), you get the runtime error because you are deleting the C++ object before the Python object. Do not call destroy yourself - call self.close and override closeEvent. From there you can accept or reject closing the dialog, and do any cleanup prior to your dialog being destroyed. From the Qt Docs: void QWidget::destroy ( bool destroyWindow = true, bool destroySubWindows = true ) [protected] Frees up window system resources. Destroys the widget window if destroyWindow is true. destroy() calls itself recursively for all the child widgets, passing destroySubWindows for the destroyWindow parameter. To have more control over destruction of subwidgets, destroy subwidgets selectively first. This function is usually called from the QWidget destructor. On Thu, Apr 7, 2011 at 3:04 AM, Rui DaCosta wrote: I know it can close it manually, the problem is that this is a simplification of a problem I had, in which we were expecting the QDialog to close as per the docs, but it did not. >The *real* problem we are facing, is a bit further down the line, where we are >getting the "RuntimeError: underlying C/C++ object has been deleted" but we >never receive a destroyed signal. >The only reason I need this signal or event is to do some teardown code for >some >callbacks to avoid getting this c++ error elsewhere. > > > > From: Demetrius Cassidy >To: RuiDC >Sent: Thu, 7 April, 2011 0:39:33 >Subject: Re: [PyQt] why do closeEvent and destroyed slot not get called on >accepting PyQt4 QDialog? > > >If you want to close, just call self.close. It's a slot, so you can map it to >any signal. Also not sure why you want to know when your widget is destroyed? >Let Python take care of it, you should not need to call sip.delete yourself. >closeEvent is there if you need to know _when_ your app was requested to >close. >If you want to allow or reject closing the app, you need to use the QEvent >object which gets passed to that function. > > >On Wed, Apr 6, 2011 at 5:27 PM, RuiDC wrote: > > >>The question & code are here: >>http://stackoverflow.com/questions/5570402/why-do-closeevent-and-destroyed-slot-not-get-called-on-accepting-pyqt4-qdialog >> >> >>but hopefully someone here can give me an answer on: >>1. how to get the closeEvent to fire from accepting (or do I have to do a >>self.close()?) >>2. how to get the destroyed message to print (or do I have to go through >>sip.delete(my_widget)?) >>3. why, if I comment out the del my_widget, and uncomment the >>my_widget.destroy() I get a: >>RuntimeError: underlying C/C++ object has been deleted >>on the destroy() without the print! i.e. how is it that it can be destroyed >>but not raise the signal? >> >>Thanks in advance, >>R >>-- >>View this message in context: >>http://old.nabble.com/why-do-closeEvent-and-destroyed-slot-not-get-called-on-accepting-PyQt4-QDialog--tp31336229p31336229.html >> >>Sent from the PyQt mailing list archive at Nabble.com. >> >>___ >>PyQt mailing listPyQt@riverbankcomputing.com >>http://www.riverbankcomputing.com/mailman/listinfo/pyqt >> > ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] why do closeEvent and destroyed slot not get called on accepting PyQt4 QDialog?
just to be clear, I wasn't trying to use destroy(), I was merely using it to demonstrate that even if I did, neither the closeEvent nor the destroyed signal were working. From: Demetrius Cassidy To: Rui DaCosta Cc: pyqt@riverbankcomputing.com Sent: Thu, 7 April, 2011 17:18:29 Subject: Re: [PyQt] why do closeEvent and destroyed slot not get called on accepting PyQt4 QDialog? Sorry found destroyed() - that's what happens when you reply to emails before you have morning coffee. Anyway I'm not sure why destroyed() is never fired. I tried your code and even modified it a bit to use the new style slots and signals but it's not being fired. Either way, I think the other points I raised in my last email are still valid. IMHO using destroyed() in python is the wrong approach. On Thu, Apr 7, 2011 at 11:02 AM, Demetrius Cassidy wrote: I truly believe you are approaching this from the wrong angle. If you need to know when your QDialog is going away, you override closeEvent and do your cleanup from there. > > >However, looking through the docs, it does not appear that destroy is actually >a >signal. It's called from the QWidget dtor, so it makes sense that if you call >destroy(), you get the runtime error because you are deleting the C++ object >before the Python object. Do not call destroy yourself - call self.close and >override closeEvent. From there you can accept or reject closing the dialog, >and >do any cleanup prior to your dialog being destroyed. > > >From the Qt Docs: > > >void QWidget::destroy ( bool destroyWindow = true, bool destroySubWindows = >true >) [protected] > >Frees up window system resources. Destroys the widget window if destroyWindow >is >true. > >destroy() calls itself recursively for all the child widgets, passing >destroySubWindows for the destroyWindow parameter. To have more control over >destruction of subwidgets, destroy subwidgets selectively first. > >This function is usually called from the QWidget destructor. > > > >On Thu, Apr 7, 2011 at 3:04 AM, Rui DaCosta wrote: > >I know it can close it manually, the problem is that this is a simplification >of >a problem I had, in which we were expecting the QDialog to close as per the >docs, but it did not. >>The *real* problem we are facing, is a bit further down the line, where we >>are >>getting the "RuntimeError: underlying C/C++ object has been deleted" but we >>never receive a destroyed signal. >>The only reason I need this signal or event is to do some teardown code for >>some >>callbacks to avoid getting this c++ error elsewhere. >> >> >> >> From: Demetrius Cassidy >>To: RuiDC >>Sent: Thu, 7 April, 2011 0:39:33 >>Subject: Re: [PyQt] why do closeEvent and destroyed slot not get called on >>accepting PyQt4 QDialog? >> >> >>If you want to close, just call self.close. It's a slot, so you can map it to >>any signal. Also not sure why you want to know when your widget is destroyed? >>Let Python take care of it, you should not need to call sip.delete yourself. >>closeEvent is there if you need to know _when_ your app was requested to >>close. >>If you want to allow or reject closing the app, you need to use the QEvent >>object which gets passed to that function. >> >> >>On Wed, Apr 6, 2011 at 5:27 PM, RuiDC wrote: >> >> >>>The question & code are here: >>>http://stackoverflow.com/questions/5570402/why-do-closeevent-and-destroyed-slot-not-get-called-on-accepting-pyqt4-qdialog >>> >>> >>>but hopefully someone here can give me an answer on: >>>1. how to get the closeEvent to fire from accepting (or do I have to do a >>>self.close()?) >>>2. how to get the destroyed message to print (or do I have to go through >>>sip.delete(my_widget)?) >>>3. why, if I comment out the del my_widget, and uncomment the >>>my_widget.destroy() I get a: >>>RuntimeError: underlying C/C++ object has been deleted >>>on the destroy() without the print! i.e. how is it that it can be destroyed >>>but not raise the signal? >>> >>>Thanks in advance, >>>R >>>-- >>>View this message in context: >>>http://old.nabble.com/why-do-closeEvent-and-destroyed-slot-not-get-called-on-accepting-PyQt4-QDialog--tp31336229p31336229.html >>> >>>Sent from the PyQt mailing list archive at Nabble.com. >>> >>>___ >>>PyQt mailing listPyQt@riverbankcomputing.com >>>http://www.riverbankcomputing.com/mailman/listinfo/pyqt >>> >> > ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] why do closeEvent and destroyed slot not get called on accepting PyQt4 QDialog?
On Thursday 07 April 2011, 17:27:15 Rui DaCosta wrote:
> Firstly thanks again for your reply,
>
> In the original code, from where this simplification is based, I have
> cleanup code on both closeEvent and destroyed, but...
>
> that's just the problem, the closeEvent isn't getting fired (unless I
> manually call close) - except when the window is closed from the
> close box.
>
> I was expecting that from the docs for done(), I would not have to on
> done(), ie. is this a bug? or are the docs incorrect?
>
> And separately, destroyed is a signal according to the docs
> http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/qobject.ht
>ml#destroyed
>
>
> but I cannot get it to fire for QDialog, no matter what I do,
> including manually calling destroy().
>
> The object appears deleted when inspected with sip.isdeleted, even
> before the destroy() - so if that is the case, why does it not raise
> a destroyed signal?
Well, looks like this is an issue in Heisenbergs uncertainty principle
domain ;-)
It's simply the GC, that's in the way. If you anchor the connect
somewhere else, the destroyed signal "gets though". If your real dialog
has a parent, you might get away with anchoring the connect there.
import sys
from PyQt4.QtGui import *
from PyQt4.QtCore import *
def pr(arg):
sys.stdout.write(arg + "\n")
sys.stdout.flush()
class Dialog(QDialog):
def __init__(self):
QDialog.__init__(self, None, Qt.WindowFlags(Qt.WA_DeleteOnClose))
self.button_box = QDialogButtonBox(self)
self.button_box.addButton(self.button_box.Ok)
self.button_box.accepted.connect(self.on_accept)
layout = QVBoxLayout()
layout.addWidget(self.button_box)
#self.setAttribute(Qt.WA_DeleteOnClose)
self.setLayout(layout)
self.destroyed.connect(self.on_destroyed)
def on_destroyed(self, *args):
pr("destroying dialog")
def on_accept(self):
pr("accepting")
self.done(42)
def closeEvent(self, event):
pr("close")
return QDialog.closeEvent(self, event)
app = QApplication([])
widget = Dialog()
widget.destroyed.connect(lambda: pr("destroyed"))
result = widget.exec_()
del widget
#my_widget.destroy()
print("result: %s" % result)
>
>
>
>
>
>
> From: Demetrius Cassidy
> To: Rui DaCosta
> Cc: pyqt@riverbankcomputing.com
> Sent: Thu, 7 April, 2011 17:02:04
> Subject: Re: [PyQt] why do closeEvent and destroyed slot not get
> called on accepting PyQt4 QDialog?
>
>
> I truly believe you are approaching this from the wrong angle. If you
> need to know when your QDialog is going away, you override closeEvent
> and do your cleanup from there.
>
> However, looking through the docs, it does not appear that destroy is
> actually a signal. It's called from the QWidget dtor, so it makes
> sense that if you call destroy(), you get the runtime error because
> you are deleting the C++ object before the Python object. Do not call
> destroy yourself - call self.close and override closeEvent. From
> there you can accept or reject closing the dialog, and do any cleanup
> prior to your dialog being destroyed.
>
> From the Qt Docs:
>
> void QWidget::destroy ( bool destroyWindow = true, bool
> destroySubWindows = true ) [protected]
>
> Frees up window system resources. Destroys the widget window if
> destroyWindow is true.
>
> destroy() calls itself recursively for all the child widgets, passing
> destroySubWindows for the destroyWindow parameter. To have more
> control over destruction of subwidgets, destroy subwidgets
> selectively first.
>
> This function is usually called from the QWidget destructor.
>
>
> On Thu, Apr 7, 2011 at 3:04 AM, Rui DaCosta wrote:
>
> I know it can close it manually, the problem is that this is a
> simplification of a problem I had, in which we were expecting the
> QDialog to close as per the docs, but it did not.
>
> >The *real* problem we are facing, is a bit further down the line,
> > where we are getting the "RuntimeError: underlying C/C++ object has
> > been deleted" but we never receive a destroyed signal.
> >The only reason I need this signal or event is to do some teardown
> > code for some callbacks to avoid getting this c++ error elsewhere.
>
>
> From: Demetrius Cassidy
>
> >To: RuiDC
> >Sent: Thu, 7 April, 2011 0:39:33
> >Subject: Re: [PyQt] why do closeEvent and destroyed slot not get
> > called on accepting PyQt4 QDialog?
> >
> >
> >If you want to close, just call self.close. It's a slot, so you can
> > map it to any signal. Also not sure why you want to know when your
> > widget is destroyed? Let Python take care of it, you should not
> > need to call sip.delete yourself. closeEvent is there if you need
> > to know _when_ your app was requested to close. If you want to
> > allow or reject closing the app, you need to use the QEvent object
> > which gets passed to that function.
> >
> >On Wed, Apr 6, 2011 at 5:27 PM, RuiDC wr
[PyQt] QabstractItemModel.match()
Hi All, Can someone point me to a working example of the QTreeView.match()function? Thanks. Frans. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Bug in QAction?
2011/4/7 Vicent Mas : > On 2011-04-07 "Hans-Peter Jansen" said: > >> On Thursday 07 April 2011, 12:12:48 Vicent Mas wrote: >> > Hi, >> > >> > I'm trying PyQt-x11-gpl-snapshot-4.8.4-8641ecc135b3 on a debian >> > testing box with Python2.7 and virtualenv-1.5.1. Running the attached >> > script raises the following error: >> > >> > (venv2.7)vmas@rachael:/tmp$ Traceback (most recent call last): >> > File "test_qaction.py", line 9, in >> > >> > shortcut=QtGui.QKeySequence.New) >> > >> > TypeError: keyword arguments are not supported >> > >> > As far as I know the support of keyword arguments has not been >> > dropped so I suppose it is a bug. Am I right or am I missing >> > something? >> >> Did this worked in earlier versions? I don't use keyword arguments much, >> but according to the builtin help, QAction simply didn't define any >> >> [...] >> > Hi, > > It works fine with PyQt4.8.3. The only documentation I know regarding this is > > http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/keyword_arguments.html > > although it is not specific to QAction. > > Vicent > Oops! I forgot to mention this one: http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/qt_properties.html Vicent -- Share what you know, learn what you don't. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Editing multiple items in QTreeView delegate
...and just to cleanup and clarify, in "ms.py", I had to go back and edit it to be: global MyTreeView instead of just simply "MyTreeView" which I wrote before... ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] QabstractItemModel.match()
hmmm, I'm not finding a match() function for either QTreeView nor QAbstractItemView... For many good code examples, try www.nullege.com ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Bug in QAction?
On Thursday 07 April 2011, 22:36:43 Vicent Mas wrote:
> 2011/4/7 Vicent Mas :
> > On 2011-04-07 "Hans-Peter Jansen" said:
> >> On Thursday 07 April 2011, 12:12:48 Vicent Mas wrote:
> >> > Hi,
> >> >
> >> > I'm trying PyQt-x11-gpl-snapshot-4.8.4-8641ecc135b3 on a debian
> >> > testing box with Python2.7 and virtualenv-1.5.1. Running the
> >> > attached script raises the following error:
> >> >
> >> > (venv2.7)vmas@rachael:/tmp$ Traceback (most recent call last):
> >> > File "test_qaction.py", line 9, in
> >> >
> >> > shortcut=QtGui.QKeySequence.New)
> >> >
> >> > TypeError: keyword arguments are not supported
> >> >
> >> > As far as I know the support of keyword arguments has not been
> >> > dropped so I suppose it is a bug. Am I right or am I missing
> >> > something?
> >>
> >> Did this worked in earlier versions? I don't use keyword arguments
> >> much, but according to the builtin help, QAction simply didn't
> >> define any
> >>
> >> [...]
> >
> > Hi,
> >
> > It works fine with PyQt4.8.3. The only documentation I know
> > regarding this is
> >
> > http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/keyword_
> >arguments.html
> >
> > although it is not specific to QAction.
> >
> > Vicent
>
> Oops! I forgot to mention this one:
>
> http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/qt_propert
>ies.html
Vicent, thanks for the reminder, and yes, something is busted here:
from PyQt4 import QtGui
app = QtGui.QApplication([])
act = QtGui.QAction('&Save', None, shortcut=QtGui.QKeySequence.Save)
Traceback (most recent call last):
File "action.py", line 4, in
act = QtGui.QAction('&Save', None, shortcut=QtGui.QKeySequence.Save)
TypeError: keyword arguments are not supported
On the pride side, the pyqtConfigure() method works still:
from PyQt4 import QtGui
app = QtGui.QApplication([])
act = QtGui.QAction('&Save', None)
act.pyqtConfigure(shortcut=QtGui.QKeySequence.Save)
Pete
python: 2.6
sip: 4.12.2-snapshot-ec9807971e08
qt4: 4.7.1
pyqt4: snapshot-4.8.4-8641ecc135b3
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
