[PyQt] Bug in QAction?

2011-04-07 Thread Vicent Mas
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 module
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 ?

2011-04-07 Thread Zoltan Szalai

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

2011-04-07 Thread Mads Ipsen

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

2011-04-07 Thread Hans-Peter Jansen
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

2011-04-07 Thread Mads Ipsen

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 ?

2011-04-07 Thread Hans-Peter Jansen
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 module
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

2011-04-07 Thread Hans-Peter Jansen
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?

2011-04-07 Thread Hans-Peter Jansen
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 module
 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?

2011-04-07 Thread Vicent Mas
On 2011-04-07 Hans-Peter Jansen h...@urpla.net 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 module

  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?

2011-04-07 Thread Demetrius Cassidy
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 ru...@yahoo.com 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 dcassid...@gmail.com
 *To:* RuiDC ru...@yahoo.com
 *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 ru...@yahoo.com 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?

2011-04-07 Thread Demetrius Cassidy
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 dcassid...@gmail.comwrote:

 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 ru...@yahoo.com 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 dcassid...@gmail.com
 *To:* RuiDC ru...@yahoo.com
 *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 ru...@yahoo.com 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?

2011-04-07 Thread Rui DaCosta
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 dcassid...@gmail.com
To: Rui DaCosta ru...@yahoo.com
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 ru...@yahoo.com 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 dcassid...@gmail.com
To: RuiDC ru...@yahoo.com
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 ru...@yahoo.com 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?

2011-04-07 Thread Rui DaCosta
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 dcassid...@gmail.com
To: Rui DaCosta ru...@yahoo.com
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 dcassid...@gmail.com 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 ru...@yahoo.com 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 dcassid...@gmail.com
To: RuiDC ru...@yahoo.com
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 ru...@yahoo.com 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?

2011-04-07 Thread Hans-Peter Jansen
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 dcassid...@gmail.com
 To: Rui DaCosta ru...@yahoo.com
 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 ru...@yahoo.com 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 dcassid...@gmail.com

 To: RuiDC ru...@yahoo.com
 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 ru...@yahoo.com wrote:
 The question  code are 

[PyQt] QabstractItemModel.match()

2011-04-07 Thread F.A.Pinkse

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-04-07 Thread Vicent Mas
2011/4/7 Vicent Mas uve...@gmail.com:
 On 2011-04-07 Hans-Peter Jansen h...@urpla.net 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 module
 
      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

2011-04-07 Thread James Polk

...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()

2011-04-07 Thread James Polk

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?

2011-04-07 Thread Hans-Peter Jansen
On Thursday 07 April 2011, 22:36:43 Vicent Mas wrote:
 2011/4/7 Vicent Mas uve...@gmail.com:
  On 2011-04-07 Hans-Peter Jansen h...@urpla.net 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 module
  
       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 module
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