[PyQt] QMainWindow bug?

Hans-Peter Jansen hpj at urpla.net
Sat Jan 22 14:13:24 GMT 2011


On Friday 21 January 2011, 08:47:13 Erik Janssens wrote:
> Hi,
>
> I wrote some general documentation around these
> issues, with regard to Camelot development, but
> it might be of use to others as well :
>
> http://downloads.conceptive.be/downloads/camelot/doc/sphinx/build/adv
>anced/development.html
>
> all remarks/corrections are welcome.

Well done, however:

> * Qt object that are not wrapped by Python
             ^
             s

> In this case PyQt is able to track when the object is deleted by Qt 
> and raises exceptions accordingly when a method of underlying Qt
> object is called  
                  ^
                  after the fact.


Now a few comments.

The pathologic cases you describe are borderline in my book and are at 
least partly due to the "thin layer" philosophy of PyQt. 

I would therefor check the behavior of Qt itself for the delete window 
and access window->statusbar case. I guess, that PyQt reflects Qt's 
behavior strictly ;-).. On the other hand, if Qt catches this case 
nicely, _then_ we should ask Phil to check, if that couldn't be done 
for PyQt, too. But a huge class hierarchy like Qt offers plenty of 
possibilities to shoot yourself in the knee. The simple advice is: 
avoid doing it, e.g. for your case: if somebody really needs to 
destruct the main window, better not access any members after the fact.

What I do not support is some your guidelines, Erik.

> Never keep a reference to objects created by Qt having a parent, so
> only use: 
> window.statusBar().objectName()

While this is fine, the following advice is ridiculous. Using references 
to gui objects is not only common practice for Qt and PyQt, that 
pattern is also used for any pyuic generated objects since ages.

The point is, if you really want to destroy objects - do it wisely, or 
refrain from it. If you add threads combined with signals and slots to 
the picture, _then_ your advice might partly make sense, say by only 
transferring simple python objects and be careful with references 
thereof. GUI objects are out of scope in this respect anyway.

Accessing GUI objects by references is just the normal course of 
actions. Using findChild and friends from the Qt introspection office 
are very useful for dynamic purposes, but they aren't designed for what 
you suggest. I bet, complex UIs, built this way would suffer from 
disastrous performance behavior.

Pete

> On Thu, 2011-01-20 at 10:22 +0100, Mailing List SVR wrote:
> > Ok, in a my pyqt app (I'm still using pyqt-4.7.x), I have a dialog
> > that require much time to open so I keep a reference to it in a app
> > global variable and I use this reference to reopen the dialog after
> > the first time. This seems to work and the dialog open much
> > quicker, however in some undeterminated cases I get:
> >
> > RuntimeError: underlying C/C++ object has been deleted
> >
> > when I get this error I recreate the dialog and update the global
> > reference,
> >
> > can you please explain the right way to keep a reference in python
> > to a qt object?
> >
> > thanks
> > NIcola
> >
> > Il giorno mer, 19/01/2011 alle 23.47 +0100, Erik Janssens ha 
scritto:
> > > there was a change in sip/pyqt from 4.8.1 to 4.8.2 regarding
> > > the detection of objects deleted by qt but still referenced in
> > > python (which is the case here).  in 4.8.1 sip/pyqt tried to
> > > detect this to avoid segfaults.  this detection however brought
> > > other issues with it, therefor the detection was turned off again
> > > in 4.8.2
> > >
> > > the solution is not to keep references in python of objects
> > > owned by qt when they might get deleted.
> > >
> > > On Wed, Jan 19, 2011 at 12:36 PM, Mailing List SVR
> > >
> > > <lists at svrinformatica.it> wrote:
> > > > I can confirm the segfault:
> > > >
> > > > - linux, kernel 2.6.36
> > > > - python 2.7.1
> > > > - pyqt 4.8.2
> > > > - qt 4.7.1
> > > >
> > > > works fine with PySide,
> > > >
> > > > Nicola
> > > >
> > > > Il giorno mer, 19/01/2011 alle 08.36 +0100, Vicent Mas ha 
scritto:
> > > >> 2011/1/18 Nick Gaens <mail at nickgaens.com>:
> > > >> > - Win7 64bit
> > > >> > - Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC
> > > >> > v.1500 32 bit (Intel)] on win32
> > > >> > - Qt v4.7.0
> > > >> > - PyQt GPL v4.8.1 for Python v2.6
> > > >> > Result: no crashes, works like a charm..
> > > >>
> > > >> Hi,
> > > >>
> > > >> I get the crash also on Windows Vista 32bit (again Python 2.6
> > > >> and PyQt 4.8.2)
> > > >>
> > > >> Vicent
> > > >
> > > > _______________________________________________
> > > > PyQt mailing list    PyQt at riverbankcomputing.com
> > > > http://www.riverbankcomputing.com/mailman/listinfo/pyqt
> > >
> > > _______________________________________________
> > > PyQt mailing list    PyQt at riverbankcomputing.com
> > > http://www.riverbankcomputing.com/mailman/listinfo/pyqt
>
> _______________________________________________
> PyQt mailing list    PyQt at riverbankcomputing.com
> http://www.riverbankcomputing.com/mailman/listinfo/pyqt




More information about the PyQt mailing list