On Thu, Jun 23, 2011 at 6:14 AM, Algis Kabaila <akaba...@pcug.org.au> wrote:
> On Thu, 23 Jun 2011 08:17:04 AM Baz Walter wrote: > > On 22/06/11 20:49, David Townshend wrote: > > > On Wed, Jun 22, 2011 at 2:34 PM, Baz Walter<baz...@ftml.net> wrote: > > >> according to the qt docs, only one application object should be > created > > >> at a time, and there is a global qApp pointer which refers to the > > >> current instance. > > >> > > >> this suggests that, in pyqt, something like the following should work: > > >> > > >> from PyQt4 import QtGui > > >> QtGui.qApp = app = QtGui.QApplication([]) > > >> app.quit() > > >> QtGui.qApp = app = None > > > > [snip] > > > > > I've investigated further and found that its caused by the gtk style > > > which I am using, since I am running gnome. Simply changing the qt > style > > > avoids the problem. I recall reading about similar issues before with > > > the gtk-qt style, so I think that this is a know problem. However, I > > > noticed that after changing the style, python still segfaults on exit. > > > gdb indicates that it is something in the QApplication destructor, and > > > it seems that deleting the > > > > > > instance after quitting solves this, e.g.: > > >>>> from PyQt4.QtGui import QApplication > > > > > >>>> for i in range(10): > > > ... app = QApplication([]) > > > ... app.quit() > > > ... del app > > > ... > > > > > >>>> exit() > > > > > > I experimented a bit with setting qApp = None, but it didn't make a > > > difference. > > > > my point was simply that you need to make sure you remove all references > > to the current qpplication instance before creating a new one. > > > > in general, setting qApp to the instance of qapplication isn't > > necessary. but it's worth noting that qApp won't refer to the same > > *pyqt* object unless it's explicitly over-written. this may become > > relevant when working with subclasses of qapplication. of course, if you > > don't use qApp, it won't make any difference, as you say ;-) > > Baz, > > This does not explain why the IDLE quits so early in the test, even before > CR > is pressed... Actually, in python3.2 if one programs in IDLE, one finds > that > IDLE is useless with PyQt as it quits (just vanishes from the screen...) if > one tries to run a script after modifying it. Basically, IDLE works only > if > it is invoked from scratch each time one wants to run a program. > > I suggest that because of such misbehaviour it is not useful to look for > faults in the test case - there is a fault, either in Python3 IDLE, Python > 3, > PyQt, Qt itself. > > As for the PyQt bug tracker - I was not able to find it, though I saw bug > reports in several places, though I said earlier that I did see it > somewhere. > > I would write it down to my aging memory.... > > OldAl. > _______________________________________________ > PyQt mailing list PyQt@riverbankcomputing.com > http://www.riverbankcomputing.com/mailman/listinfo/pyqt > Baz - Sorry, I think I misunderstood you slightly, but I reached the same conclusion - to delete all references to the instance. I don't think that omitting this should cause a segfault though, so it does look like a bug, but at least its easy to work around. OldAl - I don't get that behaviour. Is this is linux or windows, have you tried to get a backtrace to see where the problem is? I have to admit I never use IDLE, I much prefer the console interface, so I haven't had much opportunity to see if this happens to me. David
_______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt