Re: [PyQt] core dump in pyqt application
On 06.07.08 13:16:09, Iván García wrote: One of my users just reported this bug: ASSERT failure in QCoreApplication::sendEvent: Cannot send events to objects owned by a different thread. Current thread f74470. Receiver 'MainWindow' (of type 'QMainWindow') was created in thread 9a7fc0, file kernel/qcoreapplication.cpp, line 269 Cancelado (core dumped) How to avoid this problem? Is there a way to fix the problem within the application code? Yes, don't use sendEvent across threads, use postEvent. This is not 100% clear in the documentation, except that sendEvent is explained to use notify() directly. And obviously notify shouldn't be called from a different thread. Andreas -- You may get an opportunity for advancement today. Watch it! ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] pykde4 solid question
Hello there, earlier this year I wrote a graphgical frontend to lxdvdrip -- klxdvdrip. One of the functions I wrote used the supported Media function of solid to determine if the OpticalDrive is a burining device. In newer versions this code crashes. As I am eager to fix this I tried some workarounds - none of them worked. It seems to me that the SupportedMedia() function is no loinger available. Here is a code sample: curDevice = Solid.Device.allDevices() for cdrom in curDevice: if cdrom.isDeviceInterface (Solid.DeviceInterface.OpticalDrive): drive = cdrom.asDeviceInterface (Solid.DeviceInterface.Block) burner = cdrom.asDeviceInterface (Solid.DeviceInterface.OpticalDrive) print cdrom.supportedMedia() Which gives me the following error: print cdrom.supportedMedia() AttributeError: supportedMedia Am I using Solid in a wrong way? Thanks for your help Peter ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] core dump in pyqt application
Currently the app uses python threads, not pyqt threads, could this be the reason? The only thread I'm having now is a logging function: self.setTitleBarText(Trying to login...) try: if self.OSDBServer._login(username, password) : if not username: username = 'Anonymous' self.setTitleBarText(Logged as: %s % username) elif username: #We try anonymous login in case the normal user login has failed self.setTitleBarText(Error logging as: %s. Logging anonymously... % username) if self.OSDBServer._login(, ) : self.setTitleBarText(Logged as: Anonymous) else: self.setTitleBarText(Login: Cannot login.) except: self.setTitleBarText(Login: ERROR) The only interaction of the thread with the pyqt GUI is the setTitleBarText where it changes the title of the Main App Window. Andreas Pakulat wrote: On 06.07.08 13:16:09, Iván García wrote: One of my users just reported this bug: ASSERT failure in QCoreApplication::sendEvent: Cannot send events to objects owned by a different thread. Current thread f74470. Receiver 'MainWindow' (of type 'QMainWindow') was created in thread 9a7fc0, file kernel/qcoreapplication.cpp, line 269 Cancelado (core dumped) How to avoid this problem? Is there a way to fix the problem within the application code? Yes, don't use sendEvent across threads, use postEvent. This is not 100% clear in the documentation, except that sendEvent is explained to use notify() directly. And obviously notify shouldn't be called from a different thread. Andreas ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Memory leak
On Sat, 2008-07-05 at 23:04 +0100, Phil Thompson wrote: On Thu, 03 Jul 2008 16:04:42 +0200, Giovanni Bajo [EMAIL PROTECTED] wrote: Hi Phil, with SIP 4.7.6, PyQt 4.2.2, Qt 4.4.0: import sip import weakref from PyQt4.Qt import * class MyWidget(QWidget): def sizeHint(self): return QSize(900, 700) app = QApplication([]) ws = MyWidget(None) wr = weakref.ref(ws) L = QVBoxLayout(None) L.addWidget(ws) L.activate() del L del ws import gc gc.collect() assert wr() is None The assert triggers, meaning that the object of type MyWidget is not released. This appears to be a Qt problem. Although the docs say that a layout takes ownership of the widget when addWidget() is called it leaves the destruction of the widget to the eventual owner of the layout and doesn't call the widget's dtor itself. If the layout is never used (ie. never passed as an argument to QWidget.setLayout()) then all the widgets in the layout will leak. An equivalent C++ version behaves in the same way. I could change addWidget() so that the layout doesn't take ownership of the widget (ie. to match the implementation rather than the documentation) but that will break any code that creates a populated layout and returns it from a function. I believe that it's more correct if you fix this code not to have any memory leak. Either that, or you get smarter wrt when the ownership is transferred from Python to C++ (that is, when the layout is reparented to a widget, if ever). And in any case, you should probably raise this issue with Trolltech (it's at least a documentation issue, I'd say). Anyway, it turns out that I had reduced the testcase a little too much: it was not the actual memory leak I was seeing in my application. The correct testcase is this one: #!/usr/bin/env python import sip import weakref from PyQt4.Qt import * class MyWidget(QWidget): def sizeHint(self): return QSize(900, 700) app = QApplication([]) ww = QWidget(None) ws = MyWidget(None) wr = weakref.ref(ws) L = QVBoxLayout(ww) L.addWidget(ws) L.activate() del L del ws del ww import gc gc.collect() assert wr() is None This memory leak is related to the sizeHint() method (if you comment it, there's no leak anymore) and to the fact that it is actually called at least once (if you comment the .activate() call, there's no leak anymore). -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] QDialog's widgets do not show up correctly
Hi,
I'm currently learning programming with PyQt and play around a bit with
python-apt + PyQt4. My problem is as follows: In order to indicate the
progress of an apt operation, python-apt offers the possibility to pass an
instance of a progress class. In this case I subclassed FetchProgress from
apt.progress:
class GuiUpdateProgress(QDialog, FetchProgress):
def __init__(self, parent=None):
QDialog.__init__(self, parent)
FetchProgress.__init__(self)
self.items = {}
self.setModal(True)
self.fetchIndicator = QProgressBar()
self.speedIndicator = QLabel(Unknown)
self.layout = QVBoxLayout()
self.layout.addWidget(self.fetchIndicator)
self.layout.addWidget(self.speedIndicator)
self.setLayout(self.layout)
def start(self):
self.show()
def stop(self):
if 2 in self.items.values():
QMessageBox.warning(self, Update Error,
One or more sources could not be updated!)
self.hide()
def updateStatus(self, uri, descr, shortDescr, status):
self.items[uri] = status # unimportant
def pulse(self):
self.percent = ((self.currentBytes + self.currentItems)*100.0) /
float(self.totalBytes + self.totalItems)
if self.currentCPS 0:
self.eta = (self.totalBytes-self.currentBytes) /
float(self.currentCPS)
self.fetchIndicator.setValue(int(self.percent))
self.speedIndicator.setText(str(self.eta))
return True
def mediaChange(self, medium, drive):
pass # unimportant
When I now pass an instance of this class to a python-apt operation, at first
start() is called, then updateStatus() and pulse() are being called
repeatedly until the operation is done and stop() is called in the end.
I would expect this code to let a QDialog pop up, show its initial state when
start() is called and update whenever pulse() is called. However, it seems to
only show an empty window before pulse() is called the first time, and even
when pulse() is called, only the QProgressBar updates itself, the QLabel
stays invisible.
I uploaded the a tstable version of the code at http://pastebin.com/f3caddde3
to show you what I mean (python-apt is required). My PyQt Version is
(according to Synaptic) 4.3.3.
I hope somebody can tell me what I am doing wrong.
Thanks in advance.
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] pykde4 solid question
Peter Liedler wrote: Which gives me the following error: print cdrom.supportedMedia() AttributeError: supportedMedia Am I using Solid in a wrong way? If you post a complete but minimal python program which reproduces the problem, then I'll try it against KDE 4.1 and see what is going on. cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] ANN: eric4 assistant plugin released
Hi, I just released the first snapshot of the eric4 assistant plugin. It is an alternative autocompletion and calltips provider. The information is taken from QScintilla API files, the current document or from the APIs of the current project. It adjusts automatically to changes of the project. It is available via http://www.die-offenbachs.de/eric/snapshots4/plugins or the Plugin Repository dialog of eric4. Regards, Detlev -- Detlev Offenbach [EMAIL PROTECTED] ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] ANN: new eric4 and rope plugin snapshots released
Hi, I'd like to inform everybody about the immediate availability of a new eric 4.2 snapshot. It fixes a few bugs and includes these changes. - bug fixes - changed subversion relocate function to perform a relocation inside a repository - added an indication of the current editor's language to the status bar - moved all supporting project management files (e.g. tasks file) to a management subdirectory - changed the autocompletion and calltips hook support Note: the latest rope plugin snapshot is required - updated Turkish translations from Serdar Koçdaş - updated Spanish translations from Jaime Seuma It is available via http://www.die-offenbachs.de/eric/snapshots4. A new rope plugin snapshot has been uploaded as well. This needs to be installed together with the a.m. eric4 snapshot. It is available via http://www.die-offenbachs.de/eric/snapshots4/plugins or the Plugin Repository dialog of eric4. Regards, Detlev -- Detlev Offenbach [EMAIL PROTECTED] ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Memory leak
On Sun, 06 Jul 2008 15:18:10 +0200, Giovanni Bajo [EMAIL PROTECTED] wrote: On Sat, 2008-07-05 at 23:04 +0100, Phil Thompson wrote: On Thu, 03 Jul 2008 16:04:42 +0200, Giovanni Bajo [EMAIL PROTECTED] wrote: Hi Phil, with SIP 4.7.6, PyQt 4.2.2, Qt 4.4.0: import sip import weakref from PyQt4.Qt import * class MyWidget(QWidget): def sizeHint(self): return QSize(900, 700) app = QApplication([]) ws = MyWidget(None) wr = weakref.ref(ws) L = QVBoxLayout(None) L.addWidget(ws) L.activate() del L del ws import gc gc.collect() assert wr() is None The assert triggers, meaning that the object of type MyWidget is not released. This appears to be a Qt problem. Although the docs say that a layout takes ownership of the widget when addWidget() is called it leaves the destruction of the widget to the eventual owner of the layout and doesn't call the widget's dtor itself. If the layout is never used (ie. never passed as an argument to QWidget.setLayout()) then all the widgets in the layout will leak. An equivalent C++ version behaves in the same way. I could change addWidget() so that the layout doesn't take ownership of the widget (ie. to match the implementation rather than the documentation) but that will break any code that creates a populated layout and returns it from a function. I believe that it's more correct if you fix this code not to have any memory leak. I disagree, I don't work around Qt bugs in PyQt. Either that, or you get smarter wrt when the ownership is transferred from Python to C++ (that is, when the layout is reparented to a widget, if ever). The reason I'm not going to do this is that it would break lots of code (at least, lots of my code). And in any case, you should probably raise this issue with Trolltech (it's at least a documentation issue, I'd say). Agreed. Anyway, it turns out that I had reduced the testcase a little too much: it was not the actual memory leak I was seeing in my application. The correct testcase is this one: Fixed in tonight's SIP snapshot. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Virtual methods and an extra reference
On Wed, 18 Jun 2008 18:03:49 + (UTC), Kevin Watters [EMAIL PROTECTED] wrote: There's a comment in siplib.c:5300ish in the sip_api_is_py_method function that I'll reproduce here: /* * Note that the callable is never garbage collected. The main * reason for this is that it's not possible to get hold of the * method cache without make incompatible changes to the SIP * API, particularly to support the cyclic garbage collector. * It would be a lot easier if the cache was held in the * Python object rather than the derived C++ class (and this * function would be passed a cache index instead of a pointer * to the cache entry). Dropping the cache completely should * also be considered which would have the advantage of making * monkey patching predictable. With cyclic garbage collector * support we could also just save a reference to a * reimplementation that was a method rather than save the * separate components, which would also allow a borrowed * reference to the reimplementation to be returned so that the * virtual handler wouldn't need to decrement its reference * count. */ I'm tracking down a memory leak in my app--and I think it's boiling down to a virtual method on one of my classes that has an extra reference, one not coming from any Python object. This virtual method is /bound/, though, so my understanding is that it carries self in its im_self attribute and is keeping the rest of my objects alive when they shouldn't be. Should I be worried about that comment--and specifically that objects using virtual methods will leak? Reading the code seems to say otherwise; that the comment is applying to the case when a monkeypatched callable has been set on the class--not when you override a method in a subclass like usual. Phil, do you mind explaining the limitation this comment is describing a bit more? I appreciate any help! It should be fixed in tonight's SIP snapshot. It was just a Py_DECREF() that got dropped. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Memory leak
On Sun, 2008-07-06 at 17:29 +0100, Phil Thompson wrote: On Sun, 06 Jul 2008 15:18:10 +0200, Giovanni Bajo [EMAIL PROTECTED] wrote: On Sat, 2008-07-05 at 23:04 +0100, Phil Thompson wrote: On Thu, 03 Jul 2008 16:04:42 +0200, Giovanni Bajo [EMAIL PROTECTED] wrote: Hi Phil, with SIP 4.7.6, PyQt 4.2.2, Qt 4.4.0: import sip import weakref from PyQt4.Qt import * class MyWidget(QWidget): def sizeHint(self): return QSize(900, 700) app = QApplication([]) ws = MyWidget(None) wr = weakref.ref(ws) L = QVBoxLayout(None) L.addWidget(ws) L.activate() del L del ws import gc gc.collect() assert wr() is None The assert triggers, meaning that the object of type MyWidget is not released. This appears to be a Qt problem. Although the docs say that a layout takes ownership of the widget when addWidget() is called it leaves the destruction of the widget to the eventual owner of the layout and doesn't call the widget's dtor itself. If the layout is never used (ie. never passed as an argument to QWidget.setLayout()) then all the widgets in the layout will leak. An equivalent C++ version behaves in the same way. I could change addWidget() so that the layout doesn't take ownership of the widget (ie. to match the implementation rather than the documentation) but that will break any code that creates a populated layout and returns it from a function. I believe that it's more correct if you fix this code not to have any memory leak. I disagree, I don't work around Qt bugs in PyQt. Depends on whether you consider it a bug in the Qt documentation or a bug in the Qt implementation. If it's the former, probably something should be changed in PyQt as well. If it's the latter, then yes, leave it to the Trolltech guys. Either that, or you get smarter wrt when the ownership is transferred from Python to C++ (that is, when the layout is reparented to a widget, if ever). The reason I'm not going to do this is that it would break lots of code (at least, lots of my code). You can wait a major version to apply this breaker, but it's still worthwhile. I think that explicitly breaking code is better than implicitly causing memory leaks which hard to find and debug. Anyway, it turns out that I had reduced the testcase a little too much: it was not the actual memory leak I was seeing in my application. The correct testcase is this one: Fixed in tonight's SIP snapshot. Many thanks! -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] QDialog's widgets do not show up correctly
On 2008-07-06 17:39:29, Phil Thompson wrote: Modal dialogs have their own event loop. You probably need to call the dialog's exec_() method. Phil Thanks a lot for the hint about the event loop. I cannot call exec_(), as this would block the cache.update() method but regularly calling QApplication.processEvents() seems to work perfectly fine. Christoph ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] pykde4 solid question
Hi, Peter Liedler wrote: this one should be executable: if cdrom.isDeviceInterface (Solid.DeviceInterface.OpticalDrive): burner = cdrom.asDeviceInterface (Solid.DeviceInterface.OpticalDrive) print burner.supportedMedia() Looks like a bug in PyKDE. You should be getting an optical driver object back, but instead you get a drive object. It looks like something I can fix for KDE 4.1, and maybe 4.0 if there is demand for it. cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] pykde4 solid question
Simon Edwards wrote: Hi, Peter Liedler wrote: this one should be executable: if cdrom.isDeviceInterface (Solid.DeviceInterface.OpticalDrive): burner = cdrom.asDeviceInterface (Solid.DeviceInterface.OpticalDrive) print burner.supportedMedia() Looks like a bug in PyKDE. You should be getting an optical driver object back, but instead you get a drive object. It looks like something I can fix for KDE 4.1, and maybe 4.0 if there is demand for it. I just committed the fix to KDE 4.1. :-) cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | ZooTV? You made the right choice. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] core dump in pyqt application
On 06.07.08 20:34:05, Iván García wrote: Currently the app uses python threads, not pyqt threads, could this be the reason? The only thread I'm having now is a logging function: self.setTitleBarText(Trying to login...) try: if self.OSDBServer._login(username, password) : if not username: username = 'Anonymous' self.setTitleBarText(Logged as: %s % username) elif username: #We try anonymous login in case the normal user login has failed self.setTitleBarText(Error logging as: %s. Logging anonymously... % username) if self.OSDBServer._login(, ) : self.setTitleBarText(Logged as: Anonymous) else: self.setTitleBarText(Login: Cannot login.) except: self.setTitleBarText(Login: ERROR) The only interaction of the thread with the pyqt GUI is the setTitleBarText where it changes the title of the Main App Window. I guess this code runs inside your own thread? If so thats why you're having that problem. You can't call such methods from outside the GUI/main thread with Qt. Andreas -- Your talents will be recognized and suitably rewarded. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] pykde4 solid question
Thank you. I think there is no need to backport it to kde 4.0 since 4.1 is released at the end of this month and I seem to be the only one using it at this time. Peter Simon Edwards wrote: Simon Edwards wrote: Hi, Peter Liedler wrote: this one should be executable: if cdrom.isDeviceInterface (Solid.DeviceInterface.OpticalDrive): burner = cdrom.asDeviceInterface (Solid.DeviceInterface.OpticalDrive) print burner.supportedMedia() Looks like a bug in PyKDE. You should be getting an optical driver object back, but instead you get a drive object. It looks like something I can fix for KDE 4.1, and maybe 4.0 if there is demand for it. I just committed the fix to KDE 4.1. :-) cheers, ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] PyKDE4 kioslave example
I am interested in developing a simple kioslave in python, something similar to this: http://kde-apps.org/content/show.php/New+sysinfo?content=84583 I am just looking for sample code since the PyQt/PyKDE4 references are a bit C++ heavy for me to use from scratch. Thank you. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
