Re: [PyQt] Understanding PyQt Documentation
this might help, I wrote it some time ago as a reminder to myself :) http://python- camelot.s3.amazonaws.com/gpl/release/pyqt/doc/advanced/development.html On Friday, September 20, 2013 09:50:25 PM Chris O'Halloran wrote: Hello all, This question will hopefully be trivial but I seem to have a mental block. I'm currently working through Jan Bodnar's Advanced PyQt tutorial and Mark Summerfield's Rapid Gui Application Development with Python and PyQt. Both paid for copies. Thanks guys if you're on this list! I'm a novice programmer but am making reasonable progress and have worked out how to embed Matplotlib graphs within PyQt windows and use dials and sliders to manipulate the maths in the graphs. Largely through copy and modifying others code. I'm now starting to explore the toolkit beyond the tutorials - although I haven't finished either of the works mentioned in the previous paragraph. But whenever I read the PyQt documentation the following is never clear to me. This is an example from. http://pyqt.sourceforge.net/Docs/PyQt4/qpushbutton.html Say I'm wanting to make a button. quote Method Documentation QPushButton.__init__ (self, QString text, QWidget parent = None) The parent argument, if not None, causes self to be owned by Qt instead of PyQt. Constructs a push button with the parent parent and the text text. /quote code from PyQt4 import QtGui class Pluto(QtGui.QWidget): def __init__(self): super(Pluto, self).__init__() self.move(300,300) self.setWindowTitle(Size policy) self.initUI() def initUI(self): btn1 = QtGui.QPushButton(Button,self) btn1.setSizePolicy(QtGui.QSizePolicy.Fixed, QtGui.QSizePolicy.Fixed) btn2 = QtGui.QPushButton(Button2,self) /code Now consider QPushButton.__init__ (self, QString text, QWidget parent = None) and btn2 = QtGui.QPushButton(Button2,self) Obviously Button is text and can be a QString and self refers to the a QWidget but I never quite figure out what parent=None means. Is QWidget parent=None all part of one argument? is parent a key word argument? Ie you can pass other parameter to parent and not just 'None'. Is as simple as self ie the QWidget is simply the parent of the QPushButton so that when the QWidget is destroyed the QPushButton is too. How would you write parent=None? Would it be btn2 = QtGui.QPushButton(Button2) or is it btn2 = QtGui.QPushButton(Button2, parent=None) btn2 = QtGui.QPushButton(Button2, self, parent=None) And, if I write my code btn2 = QtGui.QPushButton(Button2,self) and self is the parent argument, ie not None, then I then have no idea what self being owned by Qt instead of PyQt actually means. Given that my code is bog standard, it seems a little odd that tricky things are happening with my object being owned by Qt instead of PyQt. Does this matter or have I interpreted this all incorrectly? Thanks for your patience if you've read this far. Cheers and regards, Chris O'Halloran ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] ANN: PyQt5 Snapshots Available
Hello Phil, could you possibly give some explanations for The GIL is only released when it is known to be needed. PyQt4 always released the GIL when calling Qt. Thanks, Erik On Mon, May 6, 2013 at 4:49 PM, Phil Thompson p...@riverbankcomputing.comwrote: The first PyQt5 snapshots are now available. You will need the current SIP snapshot. PyQt5 can be installed alongside PyQt4. I welcome any suggestions for additional changes - as PyQt5 is not intended to be compatible with PyQt4 it is an opportunity to fix and improve things. Current changes from PyQt4: - Versions of Python earlier than v2.6 are not supported. - PyQt4 supported a number of different API versions (QString, QVariant etc.). PyQt5 only implements v2 of those APIs for all versions of Python. - In PyQt4, QSet was implemented as a list in Python v2 and a set in Python v3. In PyQt5 QSet is always implemented as a set. - The getOpenFileNameAndFilter(), getOpenFileNamesAndFilter() and getSaveFileNameAndFilter() methods of PyQt4's QFileDialog have now been renamed getOpenFileName(), getOpenFileNames() and getSaveFileName() respectively in PyQt5. PyQt4's implementations of getOpenFileName(), getOpenFileNames() and getSaveFileName() are not supported in PyQt5. - Support for all Qt4 features that are deprecated in Qt5 has been removed. - sip.setdestroyonexit(0) is called automatically. - The GIL is only released when it is known to be needed. PyQt4 always released the GIL when calling Qt. - The QtWidgets, QtWebKitWidgets and QtPrintSupport modules have been added. - pyuic5 does not support the --pyqt3-wrapper flag of pyuic4. - pyrcc5 does not support the -py2 and -py3 flags of pyrcc4. The output of pyrcc5 is compatible with all versions of Python starting with Python v2.6. Still to do: - Removal of support for old-style connections. - Removal of any remaining deprecated and obsolete methods. - Porting of remaining examples. - Some documentation. Phil ___ 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] Camelot 13.04.13 released
Hello, Python3 support is a work in progress in a separate branch https://bitbucket.org/conceptive/camelot/commits/branch/python3.3 The idea is to jump straight to Python 3.3 and have single code base that works on Python 2.7 and 3.3 as well as supporting Qt4 and Qt5. This will not happen overnight, but will take a couple of months. Regards, Erik On Tue, Apr 16, 2013 at 5:36 PM, Sibylle Koczian nulla.epist...@web.dewrote: Am 12.04.2013 12:03, schrieb Erik Janssens: Hello, Camelot 13.04.13 has been released. Camelot provides components to build business applications on top SQLAlchemy and PyQt. For screenshots, see : http://www.python-camelot.com/ An overview of the changes can be found here : http://www.python-camelot.com/**3/post/2013/04/release-130413.**htmlhttp://www.python-camelot.com/3/post/2013/04/release-130413.html Still not for Python 3? I can't even tell from the web site, do I look in the wrong place or what? The package list for the Conceptive Python SDK mentions Python 2.7.2, but that's not the only option, even on Windows, is it? Thank you, Sibylle __**_ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.**com/mailman/listinfo/pyqthttp://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Camelot 13.04.13 released
Hello, Camelot 13.04.13 has been released. Camelot provides components to build business applications on top SQLAlchemy and PyQt. For screenshots, see : http://www.python-camelot.com/ An overview of the changes can be found here : http://www.python-camelot.com/3/post/2013/04/release-130413.html Cheers, Erik ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] intersphinx references for PyQt
Hello, would it be possible to include in the PyQt documentation's objects.inv file references to all Qt classes wrapped by PyQt. at the moment, it contains only a selection of wrapped classes, and the PyQt specific classes. there's only a few lines in the objects.inv file, such as : :py:method:`disconnect pyqt:disconnect` :py:method:`emit pyqt:emit` :py:method:`connect pyqt:connect` :py:module:`PyQt4.pyqtconfig pyqt:PyQt4.pyqtconfig` :py:module:`PyQt4.uic pyqt:PyQt4.uic` This would help a lot in writing PyQt related documentation. Thanks, Erik ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Next Releases
what kind of changes to the thread support ?? do you have links to changesets ? Thx, Erik On Tuesday, February 26, 2013 08:59:12 AM Phil Thompson wrote: I plan to make the next releases fo SIP, PyQt and QScintilla in the next few days. I've made some small changes to the thread support very recently so I would suggest anybody who makes heavy use of threads test the current snapshots to make sure nothing is broken. Phil ___ 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] Help tracking down intermittent segfault using QGraphicsItem
Here are some things regarding detecting and preventing segfaults I've once written down for my own reference : http://python-camelot.s3.amazonaws.com/gpl/release/pyqt/doc/advanced/debug.html http://python-camelot.s3.amazonaws.com/gpl/release/pyqt/doc/advanced/development.html I have not seen an undocumented segfault caused by sip or pyqt in the last year. On Sat, Jan 5, 2013 at 4:50 PM, Andreas Pakulat ap...@gmx.de wrote: Hi, On Sat, Jan 5, 2013 at 4:09 PM, Lee Harr miss...@hotmail.com wrote: I tried pynguin-0.12.zip on Windows7, python 2.7, PyQt 4.8.4 32bit, and I could run go() many times without any crashes or warnings. However, there appears to be no tournament function. Thanks for taking your time on this, but the problem is only in the development sources. I am doing my best to not make a release that is known to segfault. (Dev version uses python-3.2 and pyqt-4.9) One advise, if I may say so: The chance of finding someone who would be willing to debug your entire project is slim. On a mailing list such as this one, the best way is to reduce the problem to a self contained, minimum size test case which reproduces the bug. Yes, you are right, but I have been working on this for about a month now and the only way I've been able to get it to crash is in corner cases with the whole application running. That's why I am asking for general advice on how to find and squash a bug like this. Has anyone ever found and fixed a segfault using QGraphicsScene and QGraphicsItem before? What was the problem? What kinds of things generally cause a segfault like this? Often a segfault is caused by using a pointer (in C++) which points to a memory location thats not valid anymore, for example because the object has been deleted already. In the context of PyQt this can happen when you stop keeping references to objects that or instances of C++-provided classes in python. In such a case the C++ parts of the object will be deleted and thus any other C++ code that has a reference to the object will crash when it tries to access the object. I think thats the most common problem one encounters with PyQt4. To know why the crash happens you should generate a backtrace, this is usually rather easy on Linux and other unix-systems by enabling core-dumps via something like ulimit -c 20. Then run your program so it crashes, this should print out something like core file generated. The file will be named 'core' and will be put in the current working directory of the application at the point of the crash. You can examine it using gdb like: gdb python core thread apply all bt full That generates a backtrace which you could post here, it'll probably hint either towards the C++ code that still has a reference to an already deleted object or into some sip code that thinks it can access an object thats actually deleted already. On Windows generating a backtrace is usually easiest done using the post-mortem debugger from Visual Studio, it'll show up once the app crashes and allows you to stop at the line. In both cases you should make sure that Qt and PyQt (and possibly sip) have been built with debug symbols, otherwise you won't get references to the functions being involved. Andreas ___ 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] button delegate in a tableview
Hi Chris, I'm not sure if this can be fixed, maybe you can ask this on the Qt info mailing list. If it can be fixed, I'm interested in the solution ;) What happens is, when the TableWidget receives a click, it creates an editor, but the editor has not yet received the click. That is perfect in most cases, but in case you draw a button it isn't. Cheers, Erik On Wednesday, November 07, 2012 02:50:17 PM Cristobal Infante wrote: Hi Eric, Thanks for the tip, I've managed to get my button inside my tableview. There is only one thing that bothers me, not sure if it is a limitation or something I can fix. To be able to press a button, I need to activate the containing cell with a click. Once the cell is active I can press the button. This could become confusing for your average user. Is this fixable? Best, Cris On 6 November 2012 22:05, erik.janss...@conceptive.be wrote: The delegate itself can only paint, it cannot react to clicks, you should implement the createEditor method, the editor then reacts to clicks On Tuesday, November 06, 2012 09:59:03 PM Cristobal Infante wrote: Hi, I am trying to embed a button per row inside a tableview. My botton are drawing correctly as delegates but are not reacting to any clicks. Should I be setting flags for this column? so far I have something like: if index.column() == 14: flags |= QtCore.Qt.ItemIsSelectable | QtCore.Qt.ItemIsUserCheckable | Qt.ItemIsEnabled return flags This is my delegate, but how do I make the button react to clicks? Thanks, cris class AButton(QtGui.QStyledItemDelegate): mouse_isPressed = False def __init__(self, parent = None): QtGui.QStyledItemDelegate.__init__(self, parent) def boundingRect(self): return QtCore.QRectF(0, 0, 40, 40) def paint(self, painter, option, widget = 0): opt = QtGui.QStyleOptionButton() opt.state = ((QtGui.QStyle.State_Sunken if self.mouse_isPressed else QtGui.QStyle.State_Raised) | QtGui.QStyle.State_Enabled) opt.text = self.text() opt.icon = self.icon() opt.rect = option.rect opt.palette = option.palette QtGui.QApplication.style().drawControl(QtGui.QStyle.CE_PushButton, opt, painter) def text(self): return QtCore.QString(hi) def icon(self): return QtGui.QIcon() def mousePressEvent(self, event): self.mouse_isPressed = True print HELLO self.update() def mouseReleaseEvent(self, event): self.mouse_isPressed = False self.update() ___ 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] (no subject)
Hello Sibylle, No, it's currently not usable with Python 3. Migrating to Python 3.3 is planned for Q3 2012. The conversion process should be relatively straightforward since the new style pyqt bindings are used everywhere, and all used libraries (except for matplotlib) have been migrated to Python 3. Cheers, Erik On Sat, 2012-05-26 at 15:49 +0200, Sibylle Koczian wrote: Am 22.05.2012 00:15, schrieb Erik Janssens: you could give Camelot a try ... http://www.python-camelot.com/ Is Camelot usable with Python 3? I can't find out for sure from the website, but I suspect it's not (Windows installer only for Python 2.7). Thank you, Sibylle ___ 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] (no subject)
you could give Camelot a try ... http://www.python-camelot.com/ On Sat, May 19, 2012 at 4:16 AM, Wes Goodenough mob...@wrgoodenough.com wrote: Hello. I'm learning PyQt for use with Designer for database applications. I've been reading all the resources and tutorials, and I have a good amount of experience with GUI and Database programming in MS ACCESS. I have finally decided to put in the effort to lear python and QT but i'm stuck and need help seeing what I'm doing wrong. I have Ui_Clients.py generated by Eric from clients.ui created by Designer. class Ui_MainWindowClients(object): def setupUi(self, MainWindowClients): MainWindowClients.setObjectName(_fromUtf8(MainWindowClients)) MainWindowClients.resize(640, 480) ... etc Among the widgets is QtGui.QTreeView ClientTreeView as follows: self.ClientTreeView = QtGui.QTreeView(self.centralwidget) self.ClientTreeView.setGeometry(QtCore.QRect(30, 290, 401, 111)) ... etc ending with self.ClientTreeView.setObjectName(_fromUtf8(ClientTreeView)) I also have Clients.py as generated by Eric from clients.ui class MainWindowClients(QMainWindow, Ui_MainWindowClients): SSN, FNAME, LNAME, SEX, RACE, DOB = range(6) ASC = 0 DESC = 1 def __init__(self, parent = None): QMainWindow.__init__(self, parent) self.setupUi(self) dbType = QMYSQL dbConnect = clientsdb dbName = clients dbTable = Clients dbUname = root #because db has been created with user name dbPW = #because db password is not set db = QSqlDatabase.addDatabase(dbType, dbConnect) db.setDatabaseName(dbName) db.setUserName(dbUname) if not db.open(): QMessageBox.warning(None, ClientTracking:.join(dbName), QString(Database Open Error: %1).arg(db.lastError().text())) sys.exit(1) self.clientModel = QSqlTableModel(None, db) self.clientModel.setTable(Clients) self.clientModel.setSort(SSN, ASC) self.clientModel.select() self.ClientTreeView = QTreeView(self) self.ClientTreeView.setModel(self.clientModel) self.ClientTreeView.setGeometry(QtCore.QRect(30, 290, 401, 111)) self.ClientTreeView.show() @pyqtSignature(QString) def on_cmbBoxUniqueID_editTextChanged(self, p0): # TODO: not implemented yet ... etc My problem is in connecting self.clientModel to self.ClientTreeView. When i run this code MainWindowClients is painted including ClientTreeView from Designer (blank), but instead of having the model attached to Designer's widget ClientTreeView, a second QTreeview widget is created at default Geometry. On a related item, also note... the code snippet in the PyQt documentation explaining how to use QT Designer with PyQt contains the following for multiple inheritance instancing: The reference to self.ui.okButton.clicked.connect(self.accept) is confusing. It makes sense for the simple sub-classing of QDialog presented just before, but it does not help trying to figure out what my problem is... from PyQt4.QtGui import QDialog from ui_imagedialog import Ui_ImageDialog class ImageDialog(QDialog, Ui_ImageDialog): def __init__(self): QDialog.__init__(self) # Set up the user interface from Designer. self.setupUi(self) # Make some local modifications. self.colorDepthCombo.addItem(2 colors (1 bit per pixel)) # Connect up the buttons. self.ui.okButton.clicked.connect(self.accept) self.ui.cancelButton.clicked.connect(self.reject) Any help will be appreciated... Thanks. I'm looking forward to using the power of PyQt with MySql etc for non-MS bound projects. Wes ___ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Disturbing evidence of garbage collection error
which version of PyQt are you using ?
When in older versions (I think something like 2 releases ago),
the garbage collection kicks in in a thread and it deletes
a QObject from another thread, this object was deleted
immediately, while in recent versions those are deleted later
on in the event loop of the thread to which they belong.
You can always turn the GC of to make sure the issue is GC
related
On Fri, 2012-04-27 at 12:53 +0100, Andrew Suffield wrote:
query = QtSql.QSqlQuery()
if not query.prepare('select %s from %s where %s' %
(','.join(field_names), table, self.key_expr(table))):
I get 'RuntimeError: underlying C/C++ object has been deleted' on the
second line, with low probability. Sometimes it just segfaults instead
while inside the C++ function QSqlQuery::prepare. Either way, it
happens about one time in 100,000, and when it segfaults, a different
thread is in the garbage collector.
So, we've got one thread deciding that the local python variables of
another are garbage and freeing them, while the victim thread is still
in a function call. That implies the local variables are somehow not
getting registered properly as being referenced.
I'll keep digging, but some ideas or pointers to relevant code would
be handy - it's not immediately clear how sip interacts with GC.
___
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] Disturbing evidence of garbage collection error
and are you sure the query is being garbage collected, and not something else ? I've noticed in the past that the garbage collector often kicks in right after a query or so. Probably because of some time that has passed or something like that. On Sat, 2012-04-28 at 12:14 +0100, Andrew Suffield wrote: On Sat, Apr 28, 2012 at 01:05:37PM +0200, Erik Janssens wrote: which version of PyQt are you using ? When in older versions (I think something like 2 releases ago), the garbage collection kicks in in a thread and it deletes a QObject from another thread, this object was deleted immediately, while in recent versions those are deleted later on in the event loop of the thread to which they belong. This is on 4.9.1, but that's a different sort of bug. This is happening while query.prepare is executing - there's no way that query should be considered garbage and get collected at this point. The bug is not that it's being collecting improperly, but rather that it's being collected at all while still in use. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] debug builds under windows
Hi, How are debug builds supposed to work under windows ? I'm observing a segfault that I can only reproduce on windows, and would like to create a stackstrace. I've build Qt in debug mode. But when building sip with --debug, it appears that the dll is named sip_d instead of sip, making the dll unimportable. On a side note : I tried to build python itself in debug mode, resulting in a python_d.exe. however this exe even fails to import things like os or sys. Thanks, Erik ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] debug builds under windows
Hello Nathan, thank you for these suggestions. build python in debug succeeded in the meantime (the build directory was dirty because I had build a non debug version in the same directory by accident) now sip and pyqt build and work in debug as well but now I have to rebuild every library I use in debug :( Erik On Sat, 2012-04-14 at 08:52 -0400, Nathan Weston wrote: On 04/14/2012 05:16 AM, Erik Janssens wrote: Hi, How are debug builds supposed to work under windows ? I'm observing a segfault that I can only reproduce on windows, and would like to create a stackstrace. I've build Qt in debug mode. But when building sip with --debug, it appears that the dll is named sip_d instead of sip, making the dll unimportable. On a side note : I tried to build python itself in debug mode, resulting in a python_d.exe. however this exe even fails to import things like os or sys. Thanks, Erik I was in a similar situation a few months ago, and I eventually got it to work, but it took me a couple days of struggling with it. You have to rebuild everything in debug mode -- Python, Qt, SIP, and PyQt. The python build went smoothly for me and I didn't run into a problem like you describe -- maybe you need to adjust your PATH? In case it helps, here are the notes I wrote myself at the time: 1. Build a debug version of Python. This was pretty straightforward, just used the Visual Studio project in PC/VS8.0 (for VS2005 -- I didn't see any support for later versions). 2. Build Qt. * Download the zip file of the source distribution -- the tarball has a configure shell script, but not the configure.exe which you need for a windows build. * Open up a Visual Studio command prompt * Run configure * Build with nmake 3. Build SIP. * Set LIB to point to your python build * Run configure with your debug python * Build with nmake install 4. Build PyQt * Make sure that qmake from your Qt build is in the path. * Configure and build as above * I had to edit Makefile.release in the designer subdir to link the Python/Qt debug libs. There's also Makefile.debug but my build didn't use it. * After all that, I kept getting a link error about python26.lib -- which doesn't exist b/c the debug build has python26_d.lib. I couldn't find the problem anywhere in the Makefiles, so I just copied the lib from my regular Python 2.6 install. The build finished and it seems to work. 5. Put the debug version of Qt in your PATH I had one more weird problem when I actually ran this in the debugger: the DLLs in $QTDIR/bin don't give me any stack traces, b/c there are no PDBs there. So I had to point the path at $QTDIR/lib instead -- which contains another set of the DLLs (not sure if they're identical or not) as well as corresponding PDBs. Then it works fine. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] How SIP detects that a QObject need to destruct.
creating/deleting children does not change the refcount of a QObject, since this is done purely in C++ On Thu, 2012-03-29 at 19:22 +0800, Goldfish Huang wrote: Hi, all. I am doubted how SIP deal with QObject's cycle reference, when I try to fix some unknown memory leaks. It seems that SIP only keep a reference to QObject, whatever how many children it has. Then a QObject must have not less than 2 reference count, one from Python and another from SIP. The question is, when I delete the QObject from Python, how SIP detects that and decrease the reference? It supposed that the reference count will be decreased to 1, and never destructed. The code pastes below: import sys, gc from PyQt4.QtCore import * gc.disable() c=QObjectCleanupHandler() o1=QObject() QObject(o1), QObject(o1) c.add(o1) print sys.getrefcount(o1) , len(o1.children()) #delete a child but the reference count remains 2. o1.children()[0].setParent(None) print sys.getrefcount(o1) , len(o1.children()) #decrease reference count of o1 by one. del o1 #It is destructed! print c.isEmpty() -- 免服务器办公室聊天软件、笔记本、日记本：http://besteam.im/。 Python及Qt相关Blog：http://besteam.im/blogs/ ___ 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] QWidget 'destroyed' signal: possible regression?
Hello Pierre, Phil, I'm not so sure the current behavior is inconsistent. One of the reasons of using signal/slot over normal callbacks is that they are disconnected when one of the objects gets deleted. So if you connect the destroyed signal to a non-QObject-method, the slot is called. If you connect it to a QObject-method that has been deleted, the slot is not called. The destroyed signal is emitted in the destructor of QObject. So in case of a QWidget, this after the QWidget destructor has done its work. After this has been done, any call to a QWidget method might crash the application. I would prefer the behavior to be consistent with C++ Qt (although I don't know what that exactly is) The documentation of Qt states that the destroyed signal should be used to monitor a QObject, I don't think its intended to serve as a kind of destructor. It's worth thinking this through before changing it... Regards, Erik On Sat, 2012-03-10 at 23:48 +0100, Pierre Raybaut wrote: Well, you're quite merciless with my amateur programming skills... Anyway, thanks for taking the time to take care of it. For what it's worth, I prefer a rough exception than a silent fail. So your conclusion is fine with me. -Pierre Le 4 mars 2012 à 14:49, Phil Thompson p...@riverbankcomputing.com a écrit : On Sun, 26 Feb 2012 16:23:26 +0100, Pierre Raybaut pierre.rayb...@gmail.com wrote: Hi Phil, I recently found out that a feature succesfully tested with older versions of PyQt was broken (http://code.google.com/p/spyderlib/issues/detail?id=951) and at the same time the Matplotlib developers contacted me for a similar issue (https://github.com/matplotlib/matplotlib/issues/711). To explain our problem, I wrote this test script: #- from PyQt4.QtGui import QApplication, QWidget from PyQt4.QtCore import Qt def print_from_function(): print Callback = Function class TestWidget(QWidget): def __init__(self, parent=None): QWidget.__init__(self, parent) self.destroyed.connect(print_from_function) self.destroyed.connect(self.print_from_method) self.destroyed.connect(self.print_from_static_method) self.destroyed.connect(lambda: self.print_from_lambda_function()) self.setAttribute(Qt.WA_DeleteOnClose) def print_from_method(self): print Callback = method @staticmethod def print_from_static_method(self): print Callback = static method def print_from_lambda_function(self): print Callback = lambda function app = QApplication([]) widget = TestWidget() widget.show() app.exec_() #- The issue with the test script above is that all callbacks connected to the 'destroyed' signal are triggered except for the callback which is a method (bound to the object to be destroyed). So the question is: is this a regression from PyQt v4.8.5? (or earlier) First off I think that connecting the destroyed() signal to a method of the object being destroyed is a bug. There are no guarantees about the state of the object when the signal is emitted. The change in behaviour was introduced in SIP v4.10.3 released July 2010. As far as I can tell the change was made because I thought it was a good idea rather than in response to a bug report. The intent would have been to eliminate any C/C++ object has been deleted exceptions - but, as in this case, the slot may not make any calls that would trigger an exception. With hindsight I think I will back out the change. I dislike the inconsistency in behaviour more than I dislike the buggy application code. Phil ___ 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] need to install multiple versions of PyQt on each laptop at work
We made a custom python distribution to be able to use multiple qt/pyqt versions on the same machine without those issues. It's python 2.7 though : http://www.conceptive.be/python-sdk.html On Thu, 2012-01-26 at 21:58 -0800, Suzanne Berger wrote: I experimented with various releases of pyqt in order to determine which versions would be compatible with different versions of software that we use (Maya Mobu 2011 and 2012). I am going to have to install at least 2 different versions of PyQt on all laptops in our department. We cannot pull modules from server. I am seeking advice related to doing multiple installations of PyQt on 1 computer. We use Windows 7 64-bit. (we can't bundle using py2exe either) 1) Does PyQt installers change windows registry? 2) I noticed that after my 1st PyQt package install, subsequent installers squawked on multiple PyQt installlations. I chose separate folders directly under C drive to contain different versions. 3) I moved my initial PyQt installation from C:\Python26\Lib\site-packages to directly under C drive. If I want to uninstall this package, should I first move it back to initial location ? 4) One of the PyQt installers that I used, PyQt-Py2.6-gpl-4.6-snapshot-20090810-1.exe, completely wiped out my PATH environment variable and replaced it with that PyQt's bin directory instead of appending. I managed to restore important paths so my computer seems to be working ok, but I'm concerned about using this installer on other peoples laptops. Is it acceptable to simply copy entire installed PyQt package to other workstations. I would save in same location on C drive. 5) The other installer that I will be using: PyQt-Py2.6-gpl-4.7.3-1.exe Thanks for your feedback. Suzanne Berger ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] PyQt bug with Qt 4.8.0?
I can confirm this fix works for Qt 4.8.0 with python 2.7.2 Does this fix have side effects ? On Wed, 28 Dec 2011 18:16:13 +0100, Linos info at linos.es wrote: Hi, after Qt upgrade to 4.8.0 in my machine i have been getting problems with the painting of vertical headers in QTableViews with a QSqlQueryModel that refresh on event (for example after tab change). I have created a testcase because i wanted to report the bug to Qt bug tracker but i can't reproduce it in c++ so i have created a testcase in python with the problem and the equivalent code in c++ that not reproduces the problem, maybe i am missing something but it seems like a but in PyQt? I am using now PyQt 4.9 but i had this problem with the previous PyQt version as well, i am using arch x86_64 and python2.7 Regards, Miguel Angel. It's a PyQt bug triggered by a change in Qt v4.8.0. The fix is to remove the definition of doItemsLayout() from any .sip file they appear in (there are 4 in the QtGui module). Thanks, Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Camelot 11.11.16 released
Hello, Camelot 11.11.16 has been uploaded to PyPi. This release mainly brings the implementation of new style actions to ease customization of Camelot projects. There is a tutorial that shows its features : http://downloads.conceptive.be/downloads/camelot/doc/sphinx/build/tutorial/importer.html And reference documentation : http://downloads.conceptive.be/downloads/camelot/doc/sphinx/build/doc/actions.html Have fun with it, Erik ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] setting color of window titlebar or window background
we use a stylesheet for this purpose, they are
rather easy to implement, and you can have one
for test, pre-production, production ...
http://doc.qt.nokia.com/latest/stylesheet.html
On Mon, 2011-10-17 at 22:00 +0200, Hans-Peter Jansen wrote:
On Sunday 16 October 2011, 21:14:44 Brad Buran wrote:
When users of my program run it in test mode, it is not actively
saving data. Once in a while, a user forgets that they are in test
mode and attempts to run an experiment only to realize that the data
wasn't being saved after they're done. Is it possible to change the
color of the title bar or background to indicate that it is in test
mode? Something like a bright red title bar would be ideal, but I'm
ok with anything that I can set to visually indicate the difference
between test and data collection mode that's obvious enough to a
user.
Yes, of course, but the price is high: draw your own and mimic the
window manager behavior (move, hide, {min,max}imize, quit..).
How about coloring the background of your app, add some text to the
title bar or color your icon red?
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
[PyQt] Camelot 11.09.10 released
Hello, Camelot 11.09.10 has been released. This is a stable release with minor modifications. The most important change is probably the availability of API documentation. Regards, Erik Changes : * Refresh reexecutes queries in the table view * Deleted entities are grayed out in the GUI if they are deleted when visible * Add setup.py to new projects for easy packaging * The settings mechanism becomes plugable * Print preview does pdf export when no printer is available * Wizard to create a new project * API documentation integrated with sphinx * UserException, a subclass of Exception that to inform the user in a gentle way he should behave different. * Reduced memory usage * Table views are sorted by primary key to avoid row flicker * German, French and Dutch translations * Generation of .po files integrated with setuptools * Fixes of VirtualAddress editor ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] internalPointer crashes
what is a crash in PyQt can be a memleak in PySide ;) On Fri, 2011-08-26 at 14:12 -0400, Joel B. Mohler wrote: Hi, Back in April of this year Jeremy Sanders reported crashes when storing a python object in QModelIndex internalPointer. I've had crashes of this nature as well. It seems to work the vast majority of the time but I now have a case that seems to consistently crash although not always with the same error. Jeremy's report is at http://www.riverbankcomputing.com/pipermail/pyqt/2011- April/029719.html . The suggestion in replies there was to make sure that python had pointers to all the things in internalPointer -- I'm quite certain that my python object structure does in fact have live references so I think there is an additional bug (although maintaining live python references seems quite sensible to me). I'm currently on ubuntu 11.04 with PyQt 4.8.3 and Qt 4.7.2. I think this same crash is happening on windows vista (with Qt versions I don't have at the moment). My model source is at https://bitbucket.org/jbmohler/qtalchemy/src/69e8f006fee2/qtalchemy/PyQtModels.py in the class PBTableModel. I'd have to work a bit to prune this down to something self-complete. Of additional note is that converting everything in sight to PySide results in a non-crashing application. I'm hesitant to rush off to PySide on the basis of this bug, but it's tempting. Joel ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] segfault when using Qt.QueuedConnection
Hi, After lots of tries I have been able to get a stacktrace + core of a segfault that I believe occurs from time to time. The attached stacktrace shows the segfault is inside the QT event loop, without even involving Python. What I believe that happens is this : 1) A signal is connected to a slot with a queued connection. 2) within PyQtProxy::unislot, the sender() mehtod is called on a QObject 3) the documentation of sender() however states that the returned pointer is only valid if the sending object has not been deleted yet. I think the segfault occurs because sometimes this object has been deleted allready, and thus the casting of the sender object to its type segfaults the application sometimes. Best regards and thanks for any view on this. Erik #0 0x in ?? () #1 0x01066baf in QMetaObject::cast (this=0xe22c04, obj=0x9ba5ce8) at kernel/qmetaobject.cpp:266 #2 0x00d929b1 in qobject_castPyQtShortcircuitSignalProxy* (object=0x9ba5ce8) at ../../../install/include/QtCore/qobject.h:366 #3 0x00d91e70 in PyQtProxy::unislot (this=0xa4d5718, qargs=0xb565fb60) at qpycore_pyqtproxy.cpp:406 #4 0x00d91e08 in PyQtProxy::qt_metacall (this=0xa4d5718, _c=QMetaObject::InvokeMetaMethod, _id=1, _a=0xb565fb60) at qpycore_pyqtproxy.cpp:380 #5 0x01066b92 in QMetaObject::metacall (object=0xa4d5718, cl=QMetaObject::InvokeMetaMethod, idx=5, argv=0xb565fb60) at kernel/qmetaobject.cpp:237 #6 0x0107596b in QMetaCallEvent::placeMetaCall (this=0xb565fd30, object=0xa4d5718) at kernel/qobject.cpp:535 #7 0x010773e3 in QObject::event (this=0xa4d5718, e=0xb565fd30) at kernel/qobject.cpp:1217 #8 0x0135c27a in QApplicationPrivate::notify_helper (this=0x8a13790, receiver=0xa4d5718, e=0xb565fd30) at kernel/qapplication.cpp:4462 #9 0x01359c40 in QApplication::notify (this=0x86c5760, receiver=0xa4d5718, e=0xb565fd30) at kernel/qapplication.cpp:3862 #10 0x07735f02 in sipQApplication::notify (this=0x86c5760, a0=0xa4d5718, a1=0xb565fd30) at sipQtGuiQApplication.cpp:317 #11 0x0105f178 in QCoreApplication::notifyInternal (this=0x86c5760, receiver=0xa4d5718, event=0xb565fd30) at kernel/qcoreapplication.cpp:731 #12 0x00d3079f in QCoreApplication::sendEvent (receiver=0xa4d5718, event=0xb565fd30) at /home/tw55413/workspaces/cpd/trunk/linux2-debug/install/include/QtCore/qcoreapplication.h:215 #13 0x0106018c in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x8940ce0) at kernel/qcoreapplication.cpp:1372 #14 0x0105fe83 in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at kernel/qcoreapplication.cpp:1265 #15 0x00d307d2 in QCoreApplication::sendPostedEvents () at /home/tw55413/workspaces/cpd/trunk/linux2-debug/install/include/QtCore/qcoreapplication.h:220 #16 0x01096958 in postEventSourceDispatch (s=0x8a15388) at kernel/qeventdispatcher_glib.cpp:277 #17 0x003d8855 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #18 0x003dc668 in ?? () from /lib/libglib-2.0.so.0 #19 0x003dc848 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #20 0x010979d8 in QEventDispatcherGlib::processEvents (this=0x8a13908, flags=...) at kernel/qeventdispatcher_glib.cpp:422 #21 0x0142ee2e in QGuiEventDispatcherGlib::processEvents (this=0x8a13908, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #22 0x0105c557 in QEventLoop::processEvents (this=0xbfbf697c, flags=...) at kernel/qeventloop.cpp:149 #23 0x0105c69c in QEventLoop::exec (this=0xbfbf697c, flags=...) at kernel/qeventloop.cpp:201 #24 0x0105f801 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1008 #25 0x013598fa in QApplication::exec () at kernel/qapplication.cpp:3736 #26 0x0773a871 in meth_QApplication_exec_ (sipArgs=0xb783202c) at sipQtGuiQApplication.cpp:2266 #27 0x00a69ba2 in PyCFunction_Call (func=0x8ef72cc, arg=0xb783202c, kw=0x0) at Objects/methodobject.c:81 #28 0x00ace901 in call_function (f=0x8f4725c, throwflag=0) at Python/ceval.c:4012 #29 PyEval_EvalFrameEx (f=0x8f4725c, throwflag=0) at Python/ceval.c:2665 #30 0x00aced7f in fast_function (f=0x8a135e4, throwflag=0) at Python/ceval.c:4098 #31 call_function (f=0x8a135e4, throwflag=0) at Python/ceval.c:4033 #32 PyEval_EvalFrameEx (f=0x8a135e4, throwflag=0) at Python/ceval.c:2665 #33 0x00aced7f in fast_function (f=0x85be15c, throwflag=0) at Python/ceval.c:4098 #34 call_function (f=0x85be15c, throwflag=0) at Python/ceval.c:4033 #35 PyEval_EvalFrameEx (f=0x85be15c, throwflag=0) at Python/ceval.c:2665 #36 0x00aced7f in fast_function (f=0x859e4bc, throwflag=0) at Python/ceval.c:4098 #37 call_function (f=0x859e4bc, throwflag=0) at Python/ceval.c:4033 #38 PyEval_EvalFrameEx (f=0x859e4bc, throwflag=0) at Python/ceval.c:2665 #39 0x00ad0270 in PyEval_EvalCodeEx (co=0xb7798e78, globals=0xb786135c, locals=0xb786135c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252 #40 0x00ad03b3 in PyEval_EvalCode (co=0xb7798e78, globals=0xb786135c, locals=0xb786135c) at Python/ceval.c:666 #41 0x00acf7e6 in
[PyQt] segfault when using Qt.QueuedConnection
I've tried to create a test case for the previously reported
issue.
It appears the bug does not appear when the queued slot call
is made after the sender has been deleted, but only if the
call is made while the sender is deleted.
To run the case, use :
python -m nose.core \\
test_qt_bindings.py:SignalSlotCase.test_queued_connection_after_delete
The case is very sensitive to timings, so it might be needed
to run a couple of time.
One way or another the app gets corrupted after some time
Test the behaviour of the qt bindings in various circumstances.
import unittest
import gc
from PyQt4 import QtGui, QtCore
#
# some helper classes to create all kinds of weird object structures
#
class ReferenceHoldingBox(QtGui.QGroupBox):
A group box holding references to the table
view and the table model
def __init__(self, model, table):
QtGui.QGroupBox.__init__(self)
self.model = model
self.table = table
class TableView( QtGui.QWidget ):
A widget containg both a table and a groupbox that
holds a reference to both the table and the model of the
table
def __init__( self, table_model ):
super(TableView, self).__init__()
widget_layout = QtGui.QVBoxLayout()
table = QtGui.QTableView( self )
table.setModel( table_model )
widget_layout.addWidget( table )
widget_layout.addWidget( ReferenceHoldingBox( table_model, self ) )
self.setLayout( widget_layout )
class CyclicChildWidget(QtGui.QWidget):
def __init__( self, parent ):
super( CyclicChildWidget, self ).__init__( parent )
self._parent = parent
class CyclicWidget(QtGui.QWidget):
def __init__( self ):
super( CyclicWidget, self ).__init__()
CyclicChildWidget( self )
count_alive = lambda:sum( isinstance(o,CyclicWidget) for o in gc.get_objects() )
alive = lambda initial:count_alive()-initial
class ModelViewRegister(QtCore.QObject):
def __init__(self):
super(ModelViewRegister, self).__init__()
self.max_key = 0
self.model_by_view = dict()
def register_model_view(self, model, view):
self.max_key += 1
view.destroyed.connect( self._registered_object_destroyed )
self.model_by_view[self.max_key] = model
view.setProperty( 'registered_key', self.max_key )
@QtCore.pyqtSlot(QtCore.QObject)
def _registered_object_destroyed(self, qobject):
key, _success = qobject.property('registered_key').toLongLong()
del self.model_by_view[key]
class TableViewCases(unittest.TestCase):
Tests related to table views
def setUp(self):
from camelot.test import get_application
self.app = get_application()
def test_table_view_garbage_collection(self):
Create a table view and force its garbage collection, while
a common reference exists to both the table view and its model.
when doing so without registering the model and the view to the
ModelViewRegister, this will segfault.
register = ModelViewRegister()
for _i in range(100):
class TableModelSubclass(QtGui.QStringListModel):
pass
model = TableModelSubclass()
widget = TableView( model )
register.register_model_view(model, widget)
gc.collect()
class SignalEmitter(QtCore.QObject):
my_signal = QtCore.pyqtSignal(object)
def start_emitting(self, limit=1000):
for _i in range(limit):
o = object()
self.my_signal.emit(o)
class SignalReceiver(QtCore.QObject):
@QtCore.pyqtSlot(object)
def my_slot(self, obj):
print self.sender()
class GarbageCollectionCase( unittest.TestCase ):
def setUp(self):
self.application = QtGui.QApplication.instance()
if not self.application:
import sys
self.application = QtGui.QApplication(sys.argv)
def test_custom_garbage_collectory( self ):
from camelot.view.model_thread.garbage_collector import GarbageCollector
initial = count_alive()
collector = GarbageCollector(None, debug=True)
collector._threshold = [0, 0, 0]
self.assertFalse( alive(initial) )
cycle = CyclicWidget()
self.assertTrue( alive(initial) )
del cycle
self.assertTrue( alive(initial) )
collector._check()
self.assertFalse( alive(initial) )
def test_cyclic_dependency( self ):
Create 2 widgets with a cyclic dependency, so that they can
only be removed by the garbage collector, and then invoke the
garbage collector in a different thread.
#
# dont run this test, since it will segfault the
# interpreter
#
return
initial = count_alive()
#
[PyQt] subtle bug in PyQt in combination with Python garbage collector
Hello Phil, I believe to have found a subtle bug in PyQt in combination with the Python garbage collector. Here is what I think that happens : - A QObject is constructed in one thread, and this QObject construction contains a cyclic dependency. - this construction will not be deleted with reference counting, but only when the garbage collector is triggered - now, if the garbage collector starts collecting in a different thread then the one that the QObject was constructed in, the QObject gets destroyed in that different thread - when a QObject is destroyed, it sends events to its parent object. these events are then send in the wrong thread - this leads to corruption and/or segmentation faults To see this happening, please run the attached test case with a development build of Qt (because then, you see the assertion failure). I have observed this with : - Qt 4.7.2 - PyQt 4.8.3 - sip 4.12.1 PySide suffers from the same behavior. Thank you and best regards, Erik Test the behaviour of the qt bindings in various circumstances. import unittest from PyQt4 import QtGui, QtCore class GarbageCollectionCase( unittest.TestCase ): def setUp(self): self.application = QtGui.QApplication.instance() if not self.application: import sys self.application = QtGui.QApplication(sys.argv) def test_cyclic_dependency( self ): Create 2 widgets with a cyclic dependency, so that they can only be removed by the garbage collector, and then invoke the garbage collector in a different thread. import gc class CyclicChildWidget(QtGui.QWidget): def __init__( self, parent ): super( CyclicChildWidget, self ).__init__( parent ) self._parent = parent class CyclicWidget(QtGui.QWidget): def __init__( self ): super( CyclicWidget, self ).__init__() CyclicChildWidget( self ) # turn off automatic garbage collection, to be able to trigger it # at the 'right' time gc.disable() alive = lambda :sum( isinstance(o,CyclicWidget) for o in gc.get_objects() ) # # first proof that the wizard is only destructed by the garbage # collector # cycle = CyclicWidget() self.assertTrue( alive() ) del cycle self.assertTrue( alive() ) gc.collect() self.assertFalse( alive() ) # # now run the garbage collector in a different thread # cycle = CyclicWidget() del cycle self.assertTrue( alive() ) class GarbageCollectingThread(QtCore.QThread): def run(thread): self.assertTrue( alive() ) # assertian failure here, and core dump gc.collect() self.assertFalse( alive() ) thread = GarbageCollectingThread() thread.start() thread.wait() #0 0x00821416 in __kernel_vsyscall () #1 0x00e72941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x00e75e42 in abort () at abort.c:92 #3 0x03c2c997 in qt_message_output (msgType=QtFatalMsg, buf=0x96ea6f8 ASSERT failure in QCoreApplication::sendEvent: \Cannot send events to objects owned by a different thread. Current thread 97870f0. Receiver '' (of type 'QWidget') was created in thread 9545fa8\, file ...) at global/qglobal.cpp:2282 #4 0x03c2cb8d in qt_message (msgType=QtFatalMsg, msg=0x3dd75f4 ASSERT failure in %s: \%s\, file %s, line %d, ap=0x2d22494 \304[\343\003\360\245n\t\017[\343\003]\001) at global/qglobal.cpp:2328 #5 0x03c2cef3 in qFatal (msg=0x3dd75f4 ASSERT failure in %s: \%s\, file %s, line %d) at global/qglobal.cpp:2511 #6 0x03c2c53a in qt_assert_x (where=0x3e35bc4 QCoreApplication::sendEvent, what=0x96ea5f0 Cannot send events to objects owned by a different thread. Current thread 97870f0. Receiver '' (of type 'QWidget') was created in thread 9545fa8, file=0x3e35b0f kernel/qcoreapplication.cpp, line=349) at global/qglobal.cpp:2035 #7 0x03d5542d in QCoreApplicationPrivate::checkReceiverThread (this=0x963e810, receiver=0x96dfe08) at kernel/qcoreapplication.cpp:349 #8 0x0514e96c in QApplication::notify (this=0x9548db8, receiver=0x96dfe08, e=0x2d22914) at kernel/qapplication.cpp:3754 #9 0x01635f02 in sipQApplication::notify (this=0x9548db8, a0=0x96dfe08, a1=0x2d22914) at sipQtGuiQApplication.cpp:317 #10 0x03d56178 in QCoreApplication::notifyInternal (this=0x9548db8, receiver=0x96dfe08, event=0x2d22914) at kernel/qcoreapplication.cpp:731 #11 0x05140e3d in QCoreApplication::sendEvent (receiver=0x96dfe08, event=0x2d22914) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215 #12 0x051a781e in QWidget::~QWidget (this=0x96dfe08, __in_chrg=value optimized out) at
[PyQt] correction on bug report
PySide does not suffers from the same problem, instead it appears to have a memory leak ... ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] pyqt documentation vs qt documentation
Hi, just wanted to note that the PyQt documentation does not mark deprecated methods as such, while the Qt documentation does. eg : QHBoxLayout.setMargin is deprecated, but appears as a normal method in the PyQt docs Regards, Erik ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Inter-office distribution/installation of packages/modules
That's indeed an interesting approach. We only update a single egg (that egg than contains our app and the libraries that change most often). The application is thus able to update itself and restart itself with some kind of bootstrapper. The egg itself is in the User Data folder, so that any user is able to update its app. Don't you have issues with permissions and virus scanners and such when updating DLL's and things in C:\Program Files\... ? On Sat, 2011-07-02 at 18:43 +, Demetrius Cassidy wrote: Basically the updater is a separate python program, built using twisted. It is self contained, and can update any file on our project. The client queries the server for the client version, and if it's out of date, it launchers the patcher and quits. It's not part of py2exe itself, though it's packaged into a self contained exe with py2exe, just like our program. For our client, many dlls are updated on a regular basis for bug fixes. But you can update python code, since it's just stored in a .zip file (just have the updater dl the updated zip file and copy it over). On Tue, Jun 28, 2011 at 6:41 PM, Erik Janssens erik.janss...@conceptive.be wrote: that's interesting, how do you handle the auto update with py2exe ? which part of the app gets updated ? On Fri, Jun 17, 2011 at 12:58 AM, Demetrius Cassidy dcassid...@gmail.com wrote: We have an app which must be redistributed to multiple groups, with 40+ users and py2exe is the reason we are able to do this. Gui2exe makes the building simpler. If you need to debug, you won't be running the bundled app, so I don't see why you would need to so much other than making sure it runs when bundled. If your packages are making assumptions on how your enviroment is set up, IMO I think that is wrong and will only lead to problems down the road. And the last thing, is that we have an auto updater, so new releases only require a rebuild and push to the sever. On Jun 16, 2011 2:58 PM, Erik Janssens erik.janss...@conceptive.be wrote: Hi, I would not agree with using Py2exe, while the idea is nice, we have had many issues with it, basically for 2 reasons : - it's dependency analysis, in combination with automatic updates : if your update uses a part of a package that was not used in the original package, you need to redeploy everything, instead of just the part of your app that you update - it changes the 'environment' your app runs in (eg sys.path), while it is possible to work around it in your app, you need to make sure that none of the packages you use make certain assumption on the environment This combination means that in order to properly test your application, you need to continuously rebuild your app with py2exe, and run it. notice some error, fix it, rebuild, etc. This takes far too much time. So what we did was : - build a custom python distro with all 'binary' packages included we need that does not depend on registry settings and does not conflict with potentially other pythons installed on the machine, so we can develop, test and deploy in exactly the same environment http://www.python-camelot.com/cpd.html - build an auto-update monitoring service around it that was integrated with setuptools and buildbot http://www.conceptive.be/downloads/camelot/doc/sphinx/build/advanced/deployment.html we serve more than 100 sites with this combination. updating the app is just pressing the buildbot button which will run unittests, build a package and push it to the end users. Regards, Erik On Thu, Jun 16, 2011 at 7:13 PM, James Polk jpolk5...@yahoo.com wrote: Apologies if this is too off-topic,but I'd like to propose a discussion of how-to's and where-fore's regarding distributing python modules to a user-base. Recently, I've been using Mark Hammond's excellent pywin32 packages, along with NumPy and PyOpenGL,etc. I have a user-base
Re: [PyQt] Inter-office distribution/installation of packages/modules
that's interesting, how do you handle the auto update with py2exe ?
which part of the app gets updated ?
On Fri, Jun 17, 2011 at 12:58 AM, Demetrius Cassidy
dcassid...@gmail.com wrote:
We have an app which must be redistributed to multiple groups, with 40+
users and py2exe is the reason we are able to do this. Gui2exe makes the
building simpler.
If you need to debug, you won't be running the bundled app, so I don't see
why you would need to so much other than making sure it runs when bundled.
If your packages are making assumptions on how your enviroment is set up,
IMO I think that is wrong and will only lead to problems down the road.
And the last thing, is that we have an auto updater, so new releases only
require a rebuild and push to the sever.
On Jun 16, 2011 2:58 PM, Erik Janssens erik.janss...@conceptive.be
wrote:
Hi,
I would not agree with using Py2exe, while the idea is nice, we have had
many
issues with it, basically for 2 reasons :
- it's dependency analysis, in combination with automatic updates : if
your
update
uses a part of a package that was not used in the original package, you
need to
redeploy everything, instead of just the part of your app that you update
- it changes the 'environment' your app runs in (eg sys.path), while it is
possible
to work around it in your app, you need to make sure that none of the
packages
you use make certain assumption on the environment
This combination means that in order to properly test your application,
you
need
to continuously rebuild your app with py2exe, and run it. notice some
error,
fix it,
rebuild, etc. This takes far too much time.
So what we did was :
- build a custom python distro with all 'binary' packages included we need
that
does not depend on registry settings and does not conflict with
potentially other
pythons installed on the machine, so we can develop, test and deploy in
exactly the same environment
http://www.python-camelot.com/cpd.html
- build an auto-update monitoring service around it that was integrated
with
setuptools and buildbot
http://www.conceptive.be/downloads/camelot/doc/sphinx/build/advanced/deployment.html
we serve more than 100 sites with this combination. updating the app is
just
pressing the buildbot button which will run unittests, build a package and
push
it to the end users.
Regards,
Erik
On Thu, Jun 16, 2011 at 7:13 PM, James Polk jpolk5...@yahoo.com wrote:
Apologies if this is too off-topic,but I'd like to propose a
discussion
of
how-to's and where-fore's regarding distributing python modules to a
user-base.
Recently, I've been using Mark Hammond's excellent pywin32 packages,
along with NumPy and PyOpenGL,etc. I have a user-base of approx 40 or so,
who will need these packages added to their base Python install.
Rather than visit 40 separate desktops, I used pip (pip freeze) to get
a
short list of packages outside the base install, and wrote an app that
each
user can run to find what's missing, and initiate the appropriate
install,etc.
Then I realized that pip itself was a 3rd party package!..DOh!
I can fall back and use help('modules') to generate a new list, but it
lists
*everything* in the install,...usable but not as succinct, for pywin32
for
example,
it lists about a dozen things with a form of win32 in them,...and
doesn't
appear
to return the real package name that is associated with the binary
installation file.
Surely these issues are fairly common phenomena in many workplaces,etc...
I'm wondering if anybody out there has any knowledge, tips, or
experiences
regarding this issue that they can share.
I've found moduleFinder, and various ideas about searching sys.path,
pkgutils, but nothing else that seems like a long term viable and/or
elegant solution.
Thoughts anyone?
Thanks,
-Jim
___
PyQt mailing list PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Inter-office distribution/installation of packages/modules
Hi,
I would not agree with using Py2exe, while the idea is nice, we have had
many
issues with it, basically for 2 reasons :
- it's dependency analysis, in combination with automatic updates : if your
update
uses a part of a package that was not used in the original package, you
need to
redeploy everything, instead of just the part of your app that you update
- it changes the 'environment' your app runs in (eg sys.path), while it is
possible
to work around it in your app, you need to make sure that none of the
packages
you use make certain assumption on the environment
This combination means that in order to properly test your application, you
need
to continuously rebuild your app with py2exe, and run it. notice some error,
fix it,
rebuild, etc. This takes far too much time.
So what we did was :
- build a custom python distro with all 'binary' packages included we need
that
does not depend on registry settings and does not conflict with
potentially other
pythons installed on the machine, so we can develop, test and deploy in
exactly the same environment
http://www.python-camelot.com/cpd.html
- build an auto-update monitoring service around it that was integrated
with
setuptools and buildbot
http://www.conceptive.be/downloads/camelot/doc/sphinx/build/advanced/deployment.html
we serve more than 100 sites with this combination. updating the app is
just
pressing the buildbot button which will run unittests, build a package and
push
it to the end users.
Regards,
Erik
On Thu, Jun 16, 2011 at 7:13 PM, James Polk jpolk5...@yahoo.com wrote:
Apologies if this is too off-topic,but I'd like to propose a discussion
of
how-to's and where-fore's regarding distributing python modules to a
user-base.
Recently, I've been using Mark Hammond's excellent pywin32 packages,
along with NumPy and PyOpenGL,etc. I have a user-base of approx 40 or so,
who will need these packages added to their base Python install.
Rather than visit 40 separate desktops, I used pip (pip freeze) to get a
short list of packages outside the base install, and wrote an app that each
user can run to find what's missing, and initiate the appropriate
install,etc.
Then I realized that pip itself was a 3rd party package!..DOh!
I can fall back and use help('modules') to generate a new list, but it
lists
*everything* in the install,...usable but not as succinct, for pywin32 for
example,
it lists about a dozen things with a form of win32 in them,...and doesn't
appear
to return the real package name that is associated with the binary
installation file.
Surely these issues are fairly common phenomena in many workplaces,etc...
I'm wondering if anybody out there has any knowledge, tips, or experiences
regarding this issue that they can share.
I've found moduleFinder, and various ideas about searching sys.path,
pkgutils, but nothing else that seems like a long term viable and/or
elegant solution.
Thoughts anyone?
Thanks,
-Jim
___
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] Qt Contributors Summit
Hello Phil, good to hear you're going to the contributors summit, here are my main concerns (pretty much in line with the other responses) : - the OpenGL requirement : will this still work decent through remote desktop and citrix. imho this is important for business applications. - QML / Qt Components : having played a bit with it, I certainly see its value, BUT, I'm afraid of having certain functionality not available through C++ and hence not through PyQt. (like assembling QML scene). for PyQt applications, I see little to no value in writing a part of the app in Javascript/QML, on the contrary, it would increase complexity. After all we have been writing our gui in a dynamic language for years now. - I'm fine with deprecating certain parts of the api, to stay lean and maintainable Good luck and best regards, Erik On Wed, 2011-06-08 at 10:25 +0100, Phil Thompson wrote: I will be attending the Qt Contributors Summit next week. The primary purpose (as I understand it) is to discuss the plans for Qt5. See... http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ http://labs.qt.nokia.com/2011/05/11/responses-to-qt-5/ http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback I'm guessing that the non-C++ community won't be well represented, so feel free to give me feedback on the plans as described so far so that I can pass them on. Phil ___ 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] Qt Contributors Summit
- my concern is that we will need to build our apps using a software open gl, simply to be able to use them without difficulties for a large user base. and how this will impact the performance of remote desktop and citrix. Unfortunately, it's not up to me to dictate the users of my app to use VNC or something else. - what I mean by QML scene assembly, is how the various QDeclarativeComponents are assmbled in a QML file. for example in my apps I use : form_display = ['first_name', 'last_name', 'birthdate'] this single line will generate me a form with all the fields bound to the underlying data model. will I be able to do the same with QDeclarativeComponents without going through javascript translations and QML files. maybe my understanding of Qt Quick is still lagging, all clarifications are more then welcome ? - I agree there is certainly value in replacing the QWidgets, especially the use of anchors instead of layouts. But in our case the whole GUI is generated from the model, and this is perfectly possible with QWidgets. It would be a large step back if we had to craft our GUI by hand in some kind of wysiwyg editor. On Wed, 2011-06-08 at 14:46 +0300, Attila Csipa wrote: On Wednesday 08 June 2011 12:50:59 you wrote: - the OpenGL requirement : will this still work decent through remote desktop and citrix. imho this is important for business applications. There is no OpenGL *requirement*. It will certainly made in a way that allows extensive OpenGL optimizations (esp with Wayland and similar solutions in mind). Lighthouse IIRC already has a VNC plugin, XCB (which you can tunnel), this kind of shows you that remote connections are by no means in danger, the only question is their speed - Qt's focus is AIUI not on that ATM, so more of a 'we take patches' level. - QML / Qt Components : having played a bit with it, I certainly see its value, BUT, I'm afraid of having certain functionality not available through C++ and hence not through PyQt. (like assembling QML scene). Can you be more specific ? What do you mean under QML scene assembly ? If you are trying to dynamically generate QML, you're sorta doing it wrong - it only sounds like you're trying to put stuff in QML that shouldn't be there (or that way) in the first place. for PyQt applications, I see little to no value in writing a part of the app in Javascript/QML, on the contrary, it would increase complexity. After all we have been writing our gui in a dynamic language for years now. I used Python+QML in a couple of experiments - my personal opinion is it's way, way easier to work with QML (esp if you're willing to build your components - until Nokia makes a stable release) than it ever was with QWidget stuff. I would say this is a question of way of thinking - you're not writing *part of the app*, you're writing the UI. Best regards, Attila Csipa ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Kudos
build with VS 2008 http://www.python-camelot.com/cpd.html On Wed, Apr 20, 2011 at 7:36 AM, Eric Frederich eric.freder...@gmail.com wrote: Is there a PyQt installer built with Visual Studio? I am embedding a Python interpreter in a 3rd party application and creating bindings to that same 3rd party's libraries. Unless I am mistaken I am fairly sure that I need both Python and my bindings created using Visual Studio. I have tried to use a Python from a binary installer and was unable to import my bindings as I got DLL import errors. So, since I have gone down this route I have to manually build anything else I want available in my Python installation such as PyQT. Fortunately there was an installer for Qt built with Visual Studio. If I don't need to be doing all of this please let me know, but I at least need to build my own bindings to the 3rd party libraries using Visual Studio. On Apr 20, 2011 3:15 AM, Phil Thompson p...@riverbankcomputing.com wrote: ___ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Segfault: QGraphicsView, cyclic references, and threads
I can confirm the issue in pyqt 4.8.3 / qt 4.7.2 it segfaults, but with the following assert statement : .QObject::killTimers: timers cannot be stopped from another thread ASSERT failure in QCoreApplication::sendEvent: Cannot send events to objects owned by a different thread. Current thread b6b08490. Receiver 'qt_scrollarea_hcontainer' (of type 'QWidget') was created in thread 948, file kernel/qcoreapplication.cpp, line 349 Phil, does this mean that a QGraphicsScene is only garbage collected when the QApplication has been garbage collected, thus creating a memory leak ? The PySide equivalent however crashes as well for me, but only on exit of the app : #0 0x00273c81 in Shiboken::Object::destroy(SbkObject*, void*) () from /home/tw55413/workspaces/cpd/trunk/linux2-debug/install/lib/libshiboken-python2.7.so.1.0 #1 0x03ebbac7 in QGraphicsViewWrapper::~QGraphicsViewWrapper() () from /home/tw55413/workspaces/cpd/trunk/linux2-debug/install/lib/python2.7/site-packages/PySide/QtGui.so #2 0x005e98dc in PySide::destructionVisitor(SbkObject*, void*) () from /home/tw55413/workspaces/cpd/trunk/linux2-debug/install/lib/libpyside-python2.7.so.1.0 #3 0x002788f8 in Shiboken::BindingManager::visitAllPyObjects(void (*)(SbkObject*, void*), void*) () from /home/tw55413/workspaces/cpd/trunk/linux2-debug/install/lib/libshiboken-python2.7.so.1.0 #4 0x005e9833 in PySide::destroyQCoreApplication() () from /home/tw55413/workspaces/cpd/trunk/linux2-debug/install/lib/libpyside-python2.7.so.1.0 #5 0x005e9c77 in PySide::runCleanupFunctions() () from /home/tw55413/workspaces/cpd/trunk/linux2-debug/install/lib/libpyside-python2.7.so.1.0 #6 0x00ac4cb5 in SbkQtCoreModule___moduleShutdown(_object*) () from /home/tw55413/workspaces/cpd/trunk/linux2-debug/install/lib/python2.7/site-packages/PySide/QtCore.so #7 0x00708bf1 in PyCFunction_Call (func=0xb775ccac, arg=0xb780402c, kw=0x9bca0b4) at Objects/methodobject.c:90 #8 0x0076d504 in ext_do_call (f=0x9b4f744, throwflag=0) at Python/ceval.c:4322 #9 PyEval_EvalFrameEx (f=0x9b4f744, throwflag=0) at Python/ceval.c:2704 #10 0x0076f270 in PyEval_EvalCodeEx (co=0xb7751728, globals=0xb7752f0c, locals=0x0, args=0xb7804038, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252 #11 0x006eef17 in function_call (func=0xb7755d84, arg=0xb780402c, kw=0x0) at Objects/funcobject.c:526 #12 0x006bf59c in PyObject_Call (func=0xb7755d84, arg=0xb780402c, kw=0x0) at Objects/abstract.c:2529 #13 0x00767b94 in PyEval_CallObjectWithKeywords (func=0xb7755d84, arg=0xb780402c, kw=0x0) at Python/ceval.c:3881 #14 0x0078dc5e in call_sys_exitfunc () at Python/pythonrun.c:1726 #15 Py_Finalize () at Python/pythonrun.c:412 #16 0x007a30e1 in Py_Main (argc=2, argv=0xbfbf6e84) at Modules/main.c:624 #17 0x08048657 in main (argc=2, argv=0xbfbf6e84) at ./Modules/python.c:23 On Mon, 2011-03-28 at 12:57 +0100, Phil Thompson wrote: On Sun, 27 Mar 2011 22:29:38 -0400, Luke Campagnola lcamp...@email.unc.edu wrote: Greetings All-Knowing PyQters, I have a strange bug that's causing segmentation faults in my program. I have identified some of the key contributors to the bug and a workaround, but I would love for someone to explain what causes the crash so I can avoid similar problems in the future. Here are the things required to cause the crash: 1) Repeatedly creating and deleting a GraphicsView and GraphicsItem 2) The each GraphicsItem has a reference to the GraphicsView it is shown in 3) Having a second thread running and actively working Usually a segmentation fault will occur after roughly 10-1000 create/delete cycles. Taking away any of these components prevents the crash. The second thread does not have to be doing anything specific and does not even have to be a QThread; it just has to be doing _something_. If the Item has a weakref to its View, there is no crash (and this is a perfectly acceptable workaround). I have attached a GDB backtrace and a short script demonstrating the bug. When I run the script on my system (Ubuntu 10.04, PyQt 4.7.2), about half of the time it causes a segfault, and the rest of the time it just freezes. I've also tested the script on WinXp with PyQt 4.8.3 and 4.5.4, with similar results. PySide does not have the bug, so I suspect it is not a Qt issue. Any advice would be greatly appreciated! Luke PyQt keeps track of certain types of object that are known to cause problems if they are garbage collected before the QApplication - QGraphicsScene is one of these. It seems that QObjectCleanupHandler has problems in a threaded application. Fixed (or at least worked around) in tonight's PyQt snapshot. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ PyQt mailing listPyQt@riverbankcomputing.com
Re: [PyQt] QMainWindow bug?
Hello Pete, thank you for your feedback, I've incorporated the typos. the 'advice' put forward in the article is indeed in the context of using threads, signal-slots, closures, etc... and sooner or later any larger python app gets into this context. my experience is that the 'be careful with references' simply does not work in larger python applications. in C / C++ this kind of stuff works because you know exactly when an object will be deleted, even when you use auto pointers and the likes. In python however, that's not the case. you never know when the garbage collector will kick in and in which order it will delete objects - this leads to unreproducible behavior (and that's not theory, I have had cases where a subtle difference in order of deletion caused qt to crash). a second problem is exceptions and stack traces, when an exception is raised, a stack trace is stored, this stack trace might contain references to objects, again very difficult to know when they will go out of scope or what will happen with them. I have very concrete cases of segmentation faults that I could not track down (using gdb etc.) and those were gone once I followed my own advice ;) of not keeping reference around to objects that have parents. It might be that this segfault was due to a corner case not being handled properly in qt or pyqt, but I was unable to track it down ! and I cannot afford that my applications segfault... I'd be interested to know more about the performance implications of doing so. Which book are you refering to ?? Regards, Erik On Sat, Jan 22, 2011 at 3:13 PM, Hans-Peter Jansen h...@urpla.net wrote: 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/advyp 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
[PyQt] QWizardPage.registerField and new style signal slot ?
Hi, how is the method QWizardPage.registerField supposed to work in combination with new style signal slots ? it's third argument should be of type SIGNAL, however when passing as its third argument a QtCore.pyqtSignal object, it complains about an incorrect type. using QtCore.SIGNAL works, but this is so old style ... Thx, Erik ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] QMainWindow bug?
Hello Nicola, I'm not sure what happens when you reset the parent of a widget to None, (wether it then transfers ownership back to python). If you get that run-time error, this means that qt deleted the widget, this random effect might have been triggered by the garbage collector. you can verify this by disabling the garbage collector and see if it still happens : import gc gc.disable() I'm don't know if this trick with reparenting works, but it looks like a good trick to have speedups ?? Erik On Fri, Jan 21, 2011 at 10:21 AM, Mailing List SVR li...@svrinformatica.it wrote: Hi Erik, attacched is a small sample of what I'm doing in my app, I have a dialog that require some time to open, to speed up the things I store it in a global object and use this global object to reopen the dialog, this seems to work, I'm reusing the same dialog from different central widget, some times (I'm unable to reproduce) I see in the logs: RuntimeError: underlying C/C++ object has been deleted so I added a try except when I open the dialog, until today noone reported segfault, what do you think about this usage? thanks Nicola Il giorno ven, 21/01/2011 alle 08.47 +0100, Erik Janssens ha scritto: 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/advanced/development.html all remarks/corrections are welcome. Regards, Erik 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 li...@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 m...@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@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] QMainWindow bug?
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/advanced/development.html all remarks/corrections are welcome. Regards, Erik 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 li...@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 m...@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 listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ 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] QMainWindow bug?
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 li...@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 m...@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@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] debugging on windows
Hello All, I am trying to find the cause for a segfault that is probably Qt / PyQt related. But the segfault only happens on Windows. As I am not a windows expert, is there somebody able to explain how to debug / stacktrace / catch coredumps under windows ? All tips are appreciated. Thx, Erik ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] segfault with latest release
Hi, just got a stacktrace of a segfault under Linux. any suggestions of what I should be looking for ? Thx, Erik Program terminated with signal 11, Segmentation fault. #0 0x0019 in ?? () (gdb) bt #0 0x0019 in ?? () #1 0x0121c209 in QObject::inherits (this=0xc37b6f8, classname=0x16f6e98 QSessionManager) at /home/tw55413/workspaces/cpd/trunk/linux2-debug/install/include/QtCore/qobject.h:253 #2 0x012166ed in sipSubClass_QApplication (sipCppRet=0xbfb9a860) at /home/tw55413/workspaces/cpd/trunk/linux2-debug/PyQt-x11-gpl-snapshot-4.8.2-459d6551edc6/sip/QtGui/qapplication.sip:473 #3 0x0030491d in convertSubClass (td=0xbe8400, cppPtr=0xbfb9a8b0) at siplib.c:8320 #4 0x00304305 in sip_api_convert_from_type (cpp=0xc37b6f8, td=0xbe8400, transferObj=0x0) at siplib.c:8010 #5 0x00b47511 in Chimera::toPyObject (this=0xa2220b0, cpp=0xb54e008) at qpycore_chimera.cpp:1461 #6 0x00b3b282 in PyQtProxy::invokeSlot (slot=..., qargs=0xba9ce7c) at qpycore_pyqtproxy.cpp:460 #7 0x00b3f167 in qt_metacall_worker (pySelf=0xb622fe3c, pytype=0xa2286dc, base=0xbe8400, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xba9ce78) at qpycore_qobject_helpers.cpp:123 #8 0x00b3efd2 in qpycore_qobject_qt_metacall (pySelf=0xb622fe3c, base=0xbe8400, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xba9ce78) at qpycore_qobject_helpers.cpp:78 #9 0x00b16d90 in sipQObject::qt_metacall (this=0xb32a040, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xba9ce78) at sipQtCoreQObject.cpp:254 #10 0x00f12442 in QMetaObject::metacall (object=0xb32a040, cl=QMetaObject::InvokeMetaMethod, idx=4, argv=0xba9ce78) at kernel/qmetaobject.cpp:237 #11 0x00f1f833 in QMetaCallEvent::placeMetaCall (this=0xc01d480, object=0xb32a040) at kernel/qobject.cpp:538 #12 0x00f20f67 in QObject::event (this=0xb32a040, e=0xc01d480) at kernel/qobject.cpp:1212 #13 0x00b16ea3 in sipQObject::event (this=0xb32a040, a0=0xc01d480) at sipQtCoreQObject.cpp:274 #14 0x02d6e44e in QApplicationPrivate::notify_helper (this=0x99dae80, receiver=0xb32a040, e=0xc01d480) at kernel/qapplication.cpp:4445 #15 0x02d6bf97 in QApplication::notify (this=0x9c3dae0, receiver=0xb32a040, e=0xc01d480) at kernel/qapplication.cpp:3845 #16 0x01681512 in sipQApplication::notify (this=0x9c3dae0, a0=0xb32a040, a1=0xc01d480) at sipQtGuiQApplication.cpp:317 #17 0x00f0b710 in QCoreApplication::notifyInternal (this=0x9c3dae0, receiver=0xb32a040, event=0xc01d480) at kernel/qcoreapplication.cpp:732 #18 0x00ada64b in QCoreApplication::sendEvent (receiver=0xb32a040, event=0xc01d480) at /home/tw55413/workspaces/cpd/trunk/linux2-debug/install/include/QtCore/qcoreapplication.h:215 #19 0x00f0c6aa in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x99db390) at kernel/qcoreapplication.cpp:1370 #20 0x00f3f7ad in QEventDispatcherUNIX::processEvents (this=0x9c9bfa8, flags=...) at kernel/qeventdispatcher_unix.cpp:890 #21 0x02e2c677 in QEventDispatcherX11::processEvents (this=0x9c9bfa8, flags=...) at kernel/qeventdispatcher_x11.cpp:152 #22 0x00f0921b in QEventLoop::processEvents (this=0xbfb9b20c, flags=...) at kernel/qeventloop.cpp:149 #23 0x00f0935f in QEventLoop::exec (this=0xbfb9b20c, flags=...) at kernel/qeventloop.cpp:197 #24 0x00f0bd62 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1009 #25 0x02d6bc4e in QApplication::exec () at kernel/qapplication.cpp:3719 #26 0x01685e81 in meth_QApplication_exec_ (sipArgs=0xb77f302c) at sipQtGuiQApplication.cpp:2266 #27 0x00185242 in PyCFunction_Call (func=0xa605d8c, arg=0xb77f302c, kw=0x0) at Objects/methodobject.c:81 ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyQt API 2: equivalent of Null QVariant?
you could just access sql through python instead of through qt, NULL would then correspond to None On Tue, 2010-12-21 at 23:52 +0100, TP wrote: Phil Thompson wrote: API v1 will be supported until PyQt5 or Python v4. Is it contractual? Why Python v4? It seems to me that nobody knows when Python v4 will appear. Anyway, it seems to be a problem that API2 does not support NULL, even if it corresponds to side cases (as mine). Thanks, Julien ___ 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] segfault using daily snapshot
Hello Phil
Thank you for your assistance. Yes, threads are involved
in my tests. The segfault for sure happens during a
'deconstruction' phase, most of the time this is at the
end of the tests, but not always.
I don't think there is any recursive behavior involved,
our stress tests consist of generating a huge number of
Camelot form and table views one after another.
I tried to change the code as you suggested to :
static void clear_access_func(sipSimpleWrapper *sw)
{
sipAccessFunc old_access_func;
old_access_func = NULL;
if (sw-access_func != NULL)
{
old_access_func = sw-access_func;
sw-access_func = NULL;
}
if (old_access_func != NULL)
{
old_access_func(sw, ReleaseGuard);
}
sw-data = NULL;
}
maybe a bit too much code, but I wanted to be sure.
but it didn't help, still the same effect, I also tried
to put a SIP_BLOCK_THREADS around the code block, but it
didn't help either.
would it be possible that a single QObject has multiple
python wrappers, resulting in duplicate deletes ?
what is for sure is that when I comment out the ReleaseGuard
function, there are no segfaults.
what is the purpose of the ReleaseGuard step ? I don't find
any docs on it in the qt docs.
Maybe I should give a bit more background on the issue. We
have observed a number of segfaults with users of our application.
What is strange is that this number is far higher with
Windows 7 users. Also, on Windows 7 the crashes seem more
severe (push-the-button-time). As this is the only segfault
I'm able to produce with testing, I suspect it's this issue
causing the Windows 7 segfaults, but that's not sure of course.
What I could do is deploy a number of apps with the ReleaseGuard
line removed, to confirm this is the issue, but then I'd like
to understand what the line is about ?
Another option would be to deploy debug-builds on Windows, but
I'm really unfamiliar with doing such thing so I'd like to
avoid it.
Regards,
Erik
On Fri, 2010-12-17 at 18:47 +, Phil Thompson wrote:
On Fri, 17 Dec 2010 09:17:14 +0100, Erik Janssens
erik.janss...@conceptive.be wrote:
Hello Phil,
please find enclosed a stack trace with a debug build
of the last qt / pyqt releases.
apart from my stress-tests, I did not yet found an
easy way to reproduce it. but I'm quite sure it affects
our users as well during their daily use.
I do have a 60Mb core dump of it, but the whole debug
build is more than 700Mb.
Should you have any hints for me on how to investigate
this further...
Nothing looks obviously wrong.
Are threads involved in your tests?
Does the crash happen during normal execution, or only when the
interpreter terminates?
SIP gets the address of a C++ instance via an access function. PyQt
supplies qpointer_access_func() which uses a QPointerQObject so that it
can detect when a QObject created internally by Qt gets deleted. (PyQt can
detect when a QObject created by PyQt gets deleted by another mechanism.)
The crash is happening when the resources used to implement the QPointer
are being released when the Python object wrapping the C++ QObject is being
garbage collected.
I will assume for the moment that QPointer works properly - although I'm
not totally convinced as there seems to be a race condition in
QMetaObject::removeGuard().
Looking at the implementation of clear_access_func() in siplib.c you can
see that it tries to make sure that the resources are not freed twice by
resetting the the pointer to the access function.
Unless there is something fairly obvious that I am missing (which is quite
possible) I would start to suspect timing issues - although the stack trace
doesn't suggest any recursive behaviour.
You might want to try changing clear_access_func() so that it saves the
value of sw-access_func, clears it, then calls the access function using
the saved pointer.
Phil
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] creating QWidgets outside the GUI thread
Hi, has anybody experience with creating QWidgets outside the GUI thread ? I'd like to know if it's possible to construct QWidgets in some kind of worker thread, and when they are needed, reparent them and move them to the GUI thread before displaying them. Regards, Erik ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Fwd: creating QWidgets outside the GUI thread
well, the idea is not to initiate GUI changes from another thread. the idea is to do the construction of widgets outside the GUI thread. The reasons for this are : - I have some screens that take considerable amount of time to build up 2 to 3 seconds (widgets only, not populating the widgets with data) - during this time the GUI thread blocks. (I found that using processEvents during the construction can lead to strange behavior) - It could be used to pre-create all forms of an application in a worker thread and then move them to the GUI thread when the user requests them, resulting in super fast response times without affecting the startup time On Fri, 2010-12-17 at 13:04 +0100, KONTRA, Gergely wrote: -- Forwarded message -- From: KONTRA, Gergely pihent...@gmail.com Date: Fri, Dec 17, 2010 at 13:03 Subject: Re: [PyQt] creating QWidgets outside the GUI thread To: erik.janss...@conceptive.be AFAIK you shouldn't create or manipulate QWidgets just from the main thread. If you'd like to initiate some GUI change from a worker thread, you should use the signals slots mechanism to delegate widget creation to the main thread. +-[ Gergely Kontra pihent...@gmail.com ]--+ | | | Mobile:(+36 20)356 9656 | | | +- Olyan lángész vagyok, hogy poroltóval kellene járnom! -+ On Fri, Dec 17, 2010 at 10:29, Erik Janssens erik.janss...@conceptive.be wrote: Hi, has anybody experience with creating QWidgets outside the GUI thread ? I'd like to know if it's possible to construct QWidgets in some kind of worker thread, and when they are needed, reparent them and move them to the GUI thread before displaying them. Regards, Erik ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ 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] QLabel with tabs and newlines crashes Python
it does not crash on my python 2.7 - pyqt 4.8.1 - qt 4.7.1 build on Linux On Wed, Dec 15, 2010 at 10:07 PM, Joe Planisky joe.plani...@temboo.com wrote: Hi, I've run into a strange situation with displaying text containing tab (\t) and newline (\n) characters in a QLabel. The following code causes an immediate hard crash of python on my Windows XP system with Python 2.6, sip 4.10.5, PyQt 4.7.4, and Qt 4.6.3. from PyQt4.QtCore import * from PyQt4.QtGui import * import sys app = QApplication(sys.argv) dialog = QDialog() layout = QHBoxLayout() layout.addWidget(QLabel(test\t\n\ttest)) dialog.setLayout(layout) sys.exit(dialog.exec_()) Removing either the tabs or the newline cures the crash. The equivalent program written in C++ does NOT crash, leading me to consider that this might be a PyQt issue. How can I conclusively determine whether this is a Qt or a PyQt issue? -- Joe ___ PyQt mailing list p...@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] segfault using daily snapshot
Hello Phil, one of my stress-test revealed a segfault occuring occasionaly. I'm using a build of the latest qt release + pyqt snapshots. Unfortunately, I have not been able to reproduce it yet with a debug build. Unless this stacktrace rings a bell somewhere, I'll try to investigate it further... Regards, Erik Backtrace thread 1 == #0 0x030e9ac9 in QMetaObject::removeGuard(QObject**) () from /home/tw55413/workspaces/bootstrapper/trunk/linux2/install/lib/libQtCore.so.4 #1 0x016c9d9e in ?? () from /opt/cpd/lib/python2.7/site-packages/PyQt4/QtCore.so #2 0x00419043 in ?? () from /opt/cpd/lib/python2.7/site-packages/sip.so #3 0x00419081 in ?? () from /opt/cpd/lib/python2.7/site-packages/sip.so #4 0x080ab970 in subtype_dealloc (self=0x426ff4) at Objects/typeobject.c:1002 #5 0x08093a75 in _PyTrash_destroy_chain () at Objects/object.c:2418 #6 0x0808f0d9 in insertdict (mp=0x859adfc, key=0xb76e01a0, hash=value optimized out, value=0xa338ecc) at Objects/dictobject.c:530 #7 0x08091347 in PyDict_SetItem (op=0x859adfc, key=0xb76e01a0, value=0xa338ecc) at Objects/dictobject.c:775 #8 0x08095dbf in PyObject_GenericSetAttr (obj=0x859b4cc, name=0xb76e01a0, value=0xa338ecc) at Objects/object.c:1511 #9 0x08094a85 in PyObject_SetAttr (v=0x859b4cc, name=0xb76e01a0, value=0xa338ecc) at Objects/object.c:1245 #10 0x080e2158 in PyEval_EvalFrameEx (f=0xb4705dc, throwflag=0) at Python/ceval.c:2003 #11 0x080e5bcd in fast_function (f=0xac1f8cc, throwflag=0) at Python/ceval.c:4098 #12 call_function (f=0xac1f8cc, throwflag=0) at Python/ceval.c:4033 #13 PyEval_EvalFrameEx (f=0xac1f8cc, throwflag=0) at Python/ceval.c:2665 #14 0x080e6639 in PyEval_EvalCodeEx (co=0x8454410, globals=0x8413934, locals=0x0, args=0xa6485f8, argcount=2, kws=0xb76c0038, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252 ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] building pyqt and qt.conf
Hi, I was trying to build the latest snapshot of PyQt and for a reason I don't understand, PyQt would always build against QT installed on the system, despite pointing it explicitly to a custom QT build using the -q option. After many hours of looking, I found this was due to the fact that I had put a qt.conf file in the bin dir of QT to make it load plugins. Now I now how to fix this, but I don't understand why. What is the relation between qt.conf and the PyQt build system. The qt.conf only contained a line to set the prefix to '.' Thx, Erik ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] building pyqt and qt.conf
ok, thanks ! my build script now temporary removes qt.conf when building pyqt... On Sat, Dec 11, 2010 at 5:35 PM, Phil Thompson p...@riverbankcomputing.com wrote: On Sat, 11 Dec 2010 14:31:08 +0100, Erik Janssens erik.janss...@conceptive.be wrote: Hi, I was trying to build the latest snapshot of PyQt and for a reason I don't understand, PyQt would always build against QT installed on the system, despite pointing it explicitly to a custom QT build using the -q option. After many hours of looking, I found this was due to the fact that I had put a qt.conf file in the bin dir of QT to make it load plugins. Now I now how to fix this, but I don't understand why. What is the relation between qt.conf and the PyQt build system. The qt.conf only contained a line to set the prefix to '.' configure.py creates and runs a small C++ program that uses QLibraryInfo to get the details of the Qt configuration. The values returned are influenced by any qt.conf file. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyQt crash on windows soon after instantiating Qt objects
Hello Blaine, crashes are always interesting. can you create an as small as possible example that crashes ? if possible, run it in a debugger as well, to see where exactly it crashes, eg withing qt or pyqt or something else... Erik On Sun, Dec 12, 2010 at 2:38 AM, Blaine Bell blaine.b...@schrodinger.com wrote: Hi, I have two objects that are each subclassing QGraphicsView and QMainWindow, and I am getting the same behavior for both. Soon after I instantiate one of these objects, the process crashes. I have found that the event(QEvent *) function gets called quite a few times, then the crash happens when the event type equals QEvent::Polish (i.e., 75). Has anyone seen this before, or does anyone know what could be causing this problem? This happens soon after I instantiate these objects, and I do not do anything else with the object (i.e., I do not show() it yet) Thanks, Blaine ___ PyQt mailing list p...@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] image utilities in Qt
QImage has a 'scaled' method that can be used to create thumbnails On Sat, Dec 4, 2010 at 9:52 PM, James Polk jpolk5...@yahoo.com wrote: I've found hints that Qt supports some image handling basics.. Is there any kind of functionality for image conversion? And/or basic image resizing, cropping,etc? Something along the lines of the ImageMagick suite of programs? All I'm looking to do (at least in the short term) is generate small thumbnail images from larger ones. Any ideas or suggestions are greatly appreciated.. Cheers, -James ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Camelot 10.11.27 : leverage Python, PyQT and SQLAlchemy
Dear all, Camelot 10.11.27 has been released. This release uses the new style signal slots connections. Camelot is an open source RAD framework that leverages Python, Sqlalchemy and Qt to build database applications. Inspired by the Django admin interface, Camelot allows a developer to define the database model and Camelot will create the views. Homepage : http://www.python-camelot.com Demonstration video : http://www.youtube.com/watch?v=HZ5i257N6cc Regards, Erik New in this release : - tab based desktop - faster table view - improved search queries - much more dynamic field attributes : tooltip, background_color, editable, choices, prefix, suffix, arrow - SQLAlchemy 0.6.x support - Matplotlib integration - move to new style signal/slot connections - frozen columns in a table view ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Getting information about crash/lockup
could you post the sample to the list ? it might be of interest. fortunately I don't run on windows...but I have a windows built for testing purposes On Tue, 2010-11-02 at 21:39 +1100, Mikael Modin wrote: Hi Erik, Thanks for the tips. I have a minimal sample with the exact same bug. Got it down to 26 lines of code and one icon. I've built and run make install on the latest SIP and PyQt. If you are running Windows I could send you the sample and see if it's platform-specific. The key seem to be to be close the only visible dialog in a function that is called by a timer from a function that is called by a timer. If I move the close() up one step everything works like it should. Timer - Function - Timer - Function - close() I've tried both PyQt and PySide and the error occurs the same way in both frameworks so I assume this is based in Qt and not PyQt. I've tried running this through gdb, got the debug symbols but so far I haven't been able to make sense of it. /Mikael On 2 November 2010 17:50, Erik Janssens erik.janss...@conceptive.be wrote: Hello Mikael, first of all, you should use the latest version of PyQT / QT, because previous versions have some issues. that being said, I have had some reports of customers where our application crashes indeed only when running minimized, but I have not been unable to reproduce it. so it would be interesting if you can generate a minimal example that crashes, try to use as few QT classes as possible. when you have a minimal example, you can try to run it with pyqt and pyside, this can give you a hint wether it's qt or pyqt related. the next step is to build both pyqt and qt with debugging information on your system, this makes it easier to debug using gdb. I'd be interested in the results... regards, Erik On Tue, 2010-11-02 at 17:33 +1100, Mikael Modin wrote: Hi, I'm developing a networked multithreaded application using PyQt4 v 4.7.4. I'm wondering if there are any tools available to see what messages/signals are passed internally by Qt or if you can suggest any other good debugging tips/tools. My problem is this: The problem is related to three parts, the main window, system tray icon and a dialog. If I click a button that start things with main window in normal mode or maximized mode and the dialog pops up everything works fine. But If I click the same button, minimise the window to tray and the dialog pops up the main Qt thread dissapear from the Eclipse thread list in Debug perspective. And with it the entire gui. Which at the moment only consists of the system tray icon but I think the thread should keep running. I'm not calling close on the window when minimizing to Tray, I'm just hiding it with setVisible(false) I'm using the pydev extension with Eclipse 3.5.2. The other threads keep running without python exceptions. I don't get any python exception from the main thread. I tried running it through gdb with gdb --args python main.py to see if I could catch an exception, signal something that way, nothing. This makes me think that the thread somehow locks up completely and therefore doesn't show up in Eclipse, but it doesn't crash. /Mikael Modin ___ 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] test case for deadlock in signal / slot new style
Thanks for making my day ! I was already considering a complete refactoring to get around the issue. On Thu, 2010-10-07 at 11:09 +0100, Phil Thompson wrote: On Mon, 4 Oct 2010 22:27:59 +0200, Erik Janssens erik.janss...@conceptive.be wrote: Hi, I finally got around writting a simple test case to demonstrate the deadlock in the signal/slot new style connections. The test case can be ran using the following command : python -m nose.core -v -s test_deadlock.py:SignalSlotCase depending on the speed of your computer, it might take some tweaking to observe the deadlock, it occurs when 'emitted' and 'connected' are printed on the screen at the same time. Here are some interesting observations : - the deadlock happens independent of the QT / PyQT version - the old_style never deadlocks - this example won't work at all using PySide, it seems that PySide doesn't support queued connections involving python objects. I'm not sure what I have to do with this issue, is this a Qt, Python or PyQt issue ?? Life is so much easier with a good test case... Should be fixed in tonight's PyQt snapshot. Thanks, Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] help needed for PyQt compiling
Hi, I have no idea on how to fix your issues, but I just compiled pyqt for windows yesterday, you can download it at : http://www.python-camelot.com/get-it.html if you want. it's compiled with visual studio tough... Erik On Mon, Oct 4, 2010 at 12:18 PM, sunilrajkiran pichaimani sunilrajki...@gmail.com wrote: HI , Iam SUNIL , im in the verge of finishing the installations required to setting up an environment for developing in Qgis(open source) using MSYS for that qt was needed, i have used qt-win-opensource-4.4.0-mingw.exe and python was also needed , i compiled that too, and next PyQt was needed , i have unpacked the source code PyQt-win-gpl-4.4.4 to this location C:\msys\local\src while following these steps in a window terminal cd c:\msys\local\src\PyQt-win-gpl-4.4.2 qtvars python configure.py Error: RELEASE\QTDIRS.EXE failed to create QTDIRS.OUT,make sure your Qt v4 installation is right i got a window error saying cannot start qtdirs.exe because mingwm30.dll not found can you please give any suggestion to clear this error ___ PyQt mailing list p...@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] test case for deadlock in signal / slot new style
Hi, I finally got around writting a simple test case to demonstrate the deadlock in the signal/slot new style connections. The test case can be ran using the following command : python -m nose.core -v -s test_deadlock.py:SignalSlotCase depending on the speed of your computer, it might take some tweaking to observe the deadlock, it occurs when 'emitted' and 'connected' are printed on the screen at the same time. Here are some interesting observations : - the deadlock happens independent of the QT / PyQT version - the old_style never deadlocks - this example won't work at all using PySide, it seems that PySide doesn't support queued connections involving python objects. I'm not sure what I have to do with this issue, is this a Qt, Python or PyQt issue ?? Thanks, Erik Thread 1 #0 0x0012d422 in __kernel_vsyscall () #1 0x0013a245 in sem_wait@@GLIBC_2.1 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/sem_wait.S:80 #2 0x0810abe8 in PyThread_acquire_lock (lock=0x85debb8, waitflag=1) at ../Python/thread_pthread.h:349 #3 0x080dbe9c in PyEval_RestoreThread (tstate=0x8281060) at ../Python/ceval.c:353 #4 0x080fdc78 in PyGILState_Ensure () at ../Python/pystate.c:592 #5 0x01dc8a06 in ?? () from /usr/lib/pymodules/python2.6/PyQt4/QtCore.so #6 0x01dc495b in ?? () from /usr/lib/pymodules/python2.6/PyQt4/QtCore.so #7 0x016423d8 in QMetaType::construct (type=257, copy=0x87d1950) at kernel/qmetatype.cpp:1116 #8 0x016491cc in queued_activate (sender=value optimized out, signal=value optimized out, c=0xb7201dd8, argv=0x87c06d0, semaphore=0x0) at kernel/qobject.cpp:3166 #9 0x0164b2b1 in QMetaObject::activate (sender=0x87bf998, m=0x87bf570, local_signal_index=0, argv=0x87c06d0) at kernel/qobject.cpp:3266 #10 0x0164b9ea in QMetaObject::activate (sender=0x87bf998, signal_index=4, argv=0x87c06d0) at kernel/qobject.cpp:3346 #11 0x0164ba2b in QMetaObject::activate (sender=0x87bf998, from_signal_index=4, to_signal_index=4, argv=0x87c06d0) at kernel/qobject.cpp:3204 #12 0x01dcbda4 in ?? () from /usr/lib/pymodules/python2.6/PyQt4/QtCore.so #13 0x01dc4aec in ?? () from /usr/lib/pymodules/python2.6/PyQt4/QtCore.so Thread 2 #0 0x0012d422 in __kernel_vsyscall () #1 0x00138015 in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122 #2 0x015348c2 in QMutexPrivate::wait (this=0xb7201ec0, timeout=-1) at thread/qmutex_unix.cpp:84 #3 0x01530072 in QMutex::lock (this=0xb7201eb0) at thread/qmutex.cpp:205 #4 0x01649dfb in QOrderedMutexLocker::relock (sender=0x87bf998, signal_index=2, receiver=0xb72020d8, method_index=4, type=0, types=0x0) at ../../include/QtCore/private/../../../src/corelib/thread/qorderedmutexlocker_p.h:83 #5 QOrderedMutexLocker (sender=0x87bf998, signal_index=2, receiver=0xb72020d8, method_index=4, type=0, types=0x0) at ../../include/QtCore/private/../../../src/corelib/thread/qorderedmutexlocker_p.h:72 #6 QMetaObjectPrivate::connect (sender=0x87bf998, signal_index=2, receiver=0xb72020d8, method_index=4, type=0, types=0x0) at kernel/qobject.cpp:2908 #7 0x0164a3b2 in QObject::connect (sender=0x87bf998, signal=0x877ab00 2my_signal(PyQt_PyObject), receiver=0xb72020d8, method=0xb7202180 1my_slot(PyQt_PyObject), type=Qt::AutoConnection) at kernel/qobject.cpp:2607 #8 0x01dc4f46 in ?? () from /usr/lib/pymodules/python2.6/PyQt4/QtCore.so #9 0x01dc59e6 in ?? () from /usr/lib/pymodules/python2.6/PyQt4/QtCore.so Test the behaviour of the qt bindings in various circumstances. import unittest from PyQt4 import QtCore class SignalSlotCase( unittest.TestCase ): def setUp(self): import sys self.app = QtCore.QCoreApplication(sys.argv) def test_multiple_threads(self): class SignalEmitter(QtCore.QObject): my_signal = QtCore.pyqtSignal(object) def start_emitting(self): for i in range(1000): o = object() self.my_signal.emit(o) print 'emitted', i class SignalReceiver(QtCore.QObject): @QtCore.pyqtSlot(object) def my_slot(self, obj): print 'signal received', obj emitter = SignalEmitter() class ReceivingThread(QtCore.QThread): def run(self): receivers = [] for i in range(1000): receiver = SignalReceiver() emitter.my_signal.connect( receiver.my_slot ) receivers.append(receiver) print 'connected', i thread = ReceivingThread() thread.start() emitter.start_emitting() thread.wait()Test the behaviour of the qt bindings in various circumstances. import unittest from PyQt4 import QtCore class SignalSlotCase( unittest.TestCase ): def setUp(self):
[PyQt] qt 4.7 build for windows available
Hi, because there are some critical bugs in qt 4.7 that made our applications segfault, I have made a custom pyqt build for qt4.7, it can be downloaded from : http://www.python-camelot.com/get-it.html it's just a zip file, that you need to add to your PATH / PYTHONPATH. Regards, Erik ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] building pyqt on windows
yes indeed, I'm using MSVC2010. thanks for the warnings, I noticed too late that python itself is compiled with MSVC2008. I'm going to try to build everything from source, since I want to have full control over the stack, to be able to trace segfaults down. On Fri, 2010-10-01 at 09:00 +0100, Phil Thompson wrote: On Fri, 01 Oct 2010 09:21:27 +0200, Erik Janssens erik.janss...@conceptive.be wrote: I made some changes to sipconfig.py to get it running... On Thu, 2010-09-30 at 22:26 +0100, Phil Thompson wrote: On Thu, 30 Sep 2010 23:19:24 +0200, Erik Janssens erik.janss...@conceptive.be wrote: Hi, I'm trying to build PyQt on Windows, because I want a QT 4.7 build with OpenSSL included. And I try to build them all with the same MS compiler, to be able to debug everything afterwards. So far OpenSSL, QT and SIP build fine, but when I try to configure PyQt, it only recognizes the QtCore module. It seems as if wrong compiler options are generated, eg there is a compiler option '-lQtNetwork4' which gets dismissed, and afterwards symbols in that library are not found. Are these options generated by the configure script or by qmake, and can I change them somewhere ?? That command line is a weird combination of MSVC and MinGW flags. Are you sure everything has been built with the same compiler? Phil So you are using MSVC2010? Note the usual caveats about using Python and extension modules built with different versions of MSVC. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] building pyqt on windows
Hi, I'm trying to build PyQt on Windows, because I want a QT 4.7 build with OpenSSL included. And I try to build them all with the same MS compiler, to be able to debug everything afterwards. So far OpenSSL, QT and SIP build fine, but when I try to configure PyQt, it only recognizes the QtCore module. It seems as if wrong compiler options are generated, eg there is a compiler option '-lQtNetwork4' which gets dismissed, and afterwards symbols in that library are not found. Are these options generated by the configure script or by qmake, and can I change them somewhere ?? Thx, Erik Checking to see if the QtNetwork module should be built... cl -DUNICODE -DWIN32 -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_NO_DEBUG -DQT_NETWORK_ LIB -I. -IZ:\sandbox\bootstrapper\trunk\win32\install\mkspecs\default -IZ:\sandb ox\bootstrapper\trunk\win32\install\include\QtNetwork -IZ:\sandbox\bootstrapper\ trunk\win32\install\include -nologo -Zm200 -Zc:wchar_t- -O2 -MD -W0 cfgtest_QtNe twork.cpp -o cfgtest_QtNetwork.exe -LZ:\sandbox\bootstrapper\trunk\win32\install \lib /NOLOGO /MANIFEST /MANIFESTFILE:cfgtest_QtNetwork.manifest /SUBSYSTEM:CONSO LE /INCREMENTAL:NO -lQtNetwork4 -lQtCore4 ws2_32.lib kernel32.lib user32.lib she ll32.lib uuid.lib ole32.lib advapi32.lib cl : Command line warning D9035 : option 'o' has been deprecated and will be rem oved in a future release cl : Command line warning D9002 : ignoring unknown option '-LZ:\sandbox\bootstra pper\trunk\win32\install\lib' cl : Command line warning D9002 : ignoring unknown option '/NOLOGO' cl : Command line warning D9002 : ignoring unknown option '/MANIFEST' cl : Command line warning D9002 : ignoring unknown option '/MANIFESTFILE:cfgtest _QtNetwork.manifest' cl : Command line warning D9002 : ignoring unknown option '/SUBSYSTEM:CONSOLE' cl : Command line warning D9002 : ignoring unknown option '-lQtNetwork4' cl : Command line warning D9002 : ignoring unknown option '-lQtCore4' cfgtest_QtNetwork.cpp cfgtest_QtNetwork.obj : error LNK2019: unresolved external symbol __declspec(dl limport) public: __thiscall QHostAddress::QHostAddress(void) (__imp_??0QHostAdd ress@@q...@xz) referenced in function _main cfgtest_QtNetwork.exe : fatal error LNK1120: 1 unresolved externals Checking to see if the QtOpenGL module should be built... ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Advice for thread/process output logging, Windows debugging
Hello Steve, We've ran in more or less the same issues with the recent refactoring of Camelot, here are some things I learned (but I haven't found a decent solution yet) : - those kind of bugs tend to appear more frequent on windows than on Linux, I don't know why. But they happen on Linux as well. The best way to discover them is build stress tests and run the garbage collector explicitly in your test - try to reproduce them with stress tests on Linux, since debugging on Linux with gdb is much easier - you can as well disable the garbage collector to see if it prevents the crashes, it usually does - those crashes are related to ownership problems, see the in depth explanation of Phil : http://www.riverbankcomputing.com/pipermail/pyqt/2010-September/027705.html - there are issues when exceptions have been raised in python, since this keeps a stack trace alive with potential references to objects - some typical pythonic constructions should be avoided inside methods of Qt objects, like closures involving other Qt objects or construction of inner classes, they create difficult to track references If you learn more on this subject, I'd be very interested. Regards, Erik On Thu, 2010-09-16 at 14:48 -0500, Steve Borho wrote: Before I get to my questions, I want to congratulate you folks for such a tremendous toolkit. I can only imagine how much further along TortoiseHg would be today if we had selected PyQt from the start (which was my suggestion at the time). Our port from PyGtk is progressing very well, but we've run into a few snags that I would like some advice about. Both have to do with Mercurial commands running as Python code in a Qthread. We're giving Mercurial a modified user interface object that captures output messages and progress reports and emits them as PyQt signals [1]. What we've found is that this is fairly inefficient; commands run an order of magnitude slower than they do on the console, and they get progressively slower the longer the application is alive. I'm contemplating various buffering techniques to cut down on the number of signals, but I'm curious if people have other suggestions for making this more efficient. The second problem is that on Windows this setup can cause hard crashes after spewing a number of messages to the console like 'QObject::KillTimers: timers cannot be stopped from another thread'. Disabling the output and progress signals does not prevent these crashes, they seemed to be triggered by garbage collection, but I've been unable to determine which objects are the problematic ones. And I've been unable to reproduce the crash on Linux or Mac. What's the best way to debug this? I've downloaded the Python source and compiled a python_d.exe and dll, but even though I thought I built the same revision as the 2.6.5 release I have installed, it appears to reject all the compiled modules in my C:\Python26 folder. Is there a way to make PyQt emit more verbose error messages? ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] sip segfault in disconnectNotify
Hello Phil, I've made a unittest for the segfault, it is ran by executing the command : python -m nose.core test_qt_bindings.py It seems to be a matter of keeping too much references, rather than keeping not enough references. I know the code in itself is pointless and simply removing a line in it ensures that it doesn't segfaults, but I would like to understand why it segfaults. Thank you and best regards, Erik On Thu, 2010-09-09 at 15:46 +0100, Phil Thompson wrote: On Thu, 09 Sep 2010 16:35:15 +0200, Erik Janssens erik.janss...@conceptive.be wrote: Hi, I understand that it's possible to segfault writing python code (although in my naive view this should not be the case ;)). I'm rather convinced the code is not doing anything 'illegal', but it would be helpful to have some descriptions on what exactly one can do wrong using pyqt with regard to these kind of segfaults ? Typically not keeping a reference to an object. Historically (but I'm not sure how much it is still the case, particularly with the new-style connections) sip/PyQt would keep pointers to Python objects without taking a reference. This was to avoid creating circular references in the days before the cyclic garbage collector. I will try to write a test case for this situation, as well as for the deadlocks I mentioned earlier. Can you maybe comment on the meaning of this line in siplib.c 7288assert(PyTuple_Check(mro)); It might help me finding the cause at the python level. It's just a sanity check. If Python is working fine then mro will always be a tuple, and the following call to PyTuple_GET_SIZE() assumes that it is. If it fails then it is likely that mro has been garbage collected and the memory reused. Phil Test the behaviour of the qt bindings in various circumstances. import unittest from PyQt4 import QtGui class ReferenceHoldingBox(QtGui.QGroupBox): A group box holding references to the table view and the table model def __init__(self, model, table): QtGui.QGroupBox.__init__(self) self.model = model self.table = table class TableView( QtGui.QWidget ): A widget containg both a table and a groupbox that holds a reference to both the table and the model of the table def __init__( self, table_model ): super(TableView, self).__init__() widget_layout = QtGui.QVBoxLayout() table = QtGui.QTableView( self ) table.setModel( table_model ) widget_layout.addWidget( table ) widget_layout.addWidget( ReferenceHoldingBox( table_model, self ) ) self.setLayout( widget_layout ) class TableViewCases(unittest.TestCase): Tests related to table views def setUp(self): self.application = QtGui.QApplication([]) def test_table_view_garbage_collection(self): Create a table view and force its garbage collection import gc for i in range(100): print i class TableModelSubclass(QtGui.QStringListModel): pass widget = TableView( TableModelSubclass() ) gc.collect()___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] sip segfault in disconnectNotify
Hello Phil, I'm experiencing a segmentation fault in sip. I have build the latest released versions of sip and pyqt on ubuntu, to be able to have a decent stack trace. The issue only arises when objects are garbage collected, so I'm unsure on how to build a simple test case for it ? When I turn the python garbage collector of (gc.disable()), the segfault never appears. If there are things I can test to acquire more information, or if somebody has ideas on how to build test cases involving the garbage collector, please let me know. Please find attached the stacktrace. Best regards, Erik Program received signal SIGSEGV, Segmentation fault. 0x01f33da1 in sip_api_is_py_method (gil=0xbfff93ac, pymc=0xaf94314 , sipSelf=0xafd1104, cname=0x0, mname=0x214c5bd disconnectNotify) at siplib.c:7288 7288assert(PyTuple_Check(mro)); (gdb) bt #0 0x01f33da1 in sip_api_is_py_method (gil=0xbfff93ac, pymc=0xaf94314 , sipSelf=0xafd1104, cname=0x0, mname=0x214c5bd disconnectNotify) at siplib.c:7288 #1 0x02102875 in sipQAbstractTableModel::disconnectNotify (this=0xaf942e8, a0=0xae66d78 2rowsAboutToBeRemoved(QModelIndex,int,int)) at sipQtCoreQAbstractTableModel.cpp:712 #2 0x018ecddc in QObject::disconnect (sender=0xaf942e8, signal=0x158ad7c 2rowsAboutToBeRemoved(QModelIndex,int,int), receiver=0xb067a20, method=0x15a6f04 1_q_rowsAboutToBeRemoved(QModelIndex,int,int)) at kernel/qobject.cpp:2786 #3 0x01421a90 in ~QItemSelectionModel (this=0xb067a20, __in_chrg=value optimized out) at itemviews/qitemselectionmodel.cpp:964 #4 0x018e518f in QObjectPrivate::deleteChildren (this=0xa6bee40) at kernel/qobject.cpp:1986 #5 0x00e8c3d3 in ~QWidget (this=0xb013cc0, __in_chrg=value optimized out) at kernel/qwidget.cpp:1469 #6 0x012812d1 in ~QFrame (this=0xb013cc0, __in_chrg=value optimized out) at widgets/qframe.cpp:242 #7 0x0131d114 in ~QAbstractScrollArea (this=0xb013cc0, __in_chrg=value optimized out) at widgets/qabstractscrollarea.cpp:524 #8 0x013c2081 in ~QAbstractItemView (this=0xb013cc0, __in_chrg=value optimized out) at itemviews/qabstractitemview.cpp:598 #9 0x013d2bd5 in ~QHeaderView (this=0xb013cc0, __in_chrg=value optimized out) at itemviews/qheaderview.cpp:339 #10 0x018e518f in QObjectPrivate::deleteChildren (this=0xa6bfeb0) at kernel/qobject.cpp:1986 #11 0x00e8c3d3 in ~QWidget (this=0xb043740, __in_chrg=value optimized out) at kernel/qwidget.cpp:1469 #12 0x012812d1 in ~QFrame (this=0xb043740, __in_chrg=value optimized out) at widgets/qframe.cpp:242 #13 0x0131d114 in ~QAbstractScrollArea (this=0xb043740, __in_chrg=value optimized out) at widgets/qabstractscrollarea.cpp:524 #14 0x013c2081 in ~QAbstractItemView (this=0xb043740, __in_chrg=value optimized out) at itemviews/qabstractitemview.cpp:598 #15 0x013f8c81 in ~QTableView (this=0xb043740, __in_chrg=value optimized out) at itemviews/qtableview.cpp:1061 #16 0x007bf224 in ~sipQTableView (this=0xb043740, __in_chrg=value optimized out) at sipQtGuiQTableView.cpp:405 #17 0x018e518f in QObjectPrivate::deleteChildren (this=0xa6af0a0) at kernel/qobject.cpp:1986 #18 0x00e8c3d3 in ~QWidget (this=0xafa27c0, __in_chrg=value optimized out) at kernel/qwidget.cpp:1469 #19 0x00b05936 in ~sipQWidget (this=0xafa27c0, __in_chrg=value optimized out) at sipQtGuiQWidget.cpp:339 #20 0x018e518f in QObjectPrivate::deleteChildren (this=0xb09f5f8) at kernel/qobject.cpp:1986 #21 0x00e8c3d3 in ~QWidget (this=0xaf09278, __in_chrg=value optimized out) at kernel/qwidget.cpp:1469 #22 0x012812d1 in ~QFrame (this=0xaf09278, __in_chrg=value optimized out) at widgets/qframe.cpp:242 #23 0x012eb603 in ~QSplitter (this=0xaf09278, __in_chrg=value optimized out) at widgets/qsplitter.cpp:1029 #24 0x0081a518 in ~sipQSplitter (this=0xaf09278, __in_chrg=value optimized out) at sipQtGuiQSplitter.cpp:330 #25 0x018e518f in QObjectPrivate::deleteChildren (this=0xbe0c3f0) at kernel/qobject.cpp:1986 #26 0x00e8c3d3 in ~QWidget (this=0xa6b14c8, __in_chrg=value optimized out) at kernel/qwidget.cpp:1469 #27 0x00b05936 in ~sipQWidget (this=0xa6b14c8, __in_chrg=value optimized out) at sipQtGuiQWidget.cpp:339 #28 0x00b1ac7d in release_QWidget (sipCppV=0xa6b14c8, sipState=6) at sipQtGuiQWidget.cpp:9360 #29 0x00b1ad1b in dealloc_QWidget (sipSelf=0xad70a94) at sipQtGuiQWidget.cpp:9376 #30 0x01f36e56 in forgetObject (sw=0xad70a94) at siplib.c:9746 #31 0x01f36685 in sipWrapper_dealloc (self=0xad70a94) at siplib.c:9301 #32 0x080ab5c3 in subtype_dealloc (self=SelectView at remote 0xad70a94) at ../Objects/typeobject.c:1019 #33 0x081625ea in cell_dealloc (op=0xabef83c) at ../Objects/cellobject.c:50 #34 0x080a8a44 in tupledealloc (op=0xb0f53ac) at ../Objects/tupleobject.c:170 #35 0x0816b4f3 in func_dealloc (op=0xb0ea17c) at ../Objects/funcobject.c:461 #36 0x0816247b in cell_clear (op=0xad81df4) at ../Objects/cellobject.c:93 #37 0x0810d1be in delete_garbage (generation=value optimized out) at ../Modules/gcmodule.c:714 #38 collect (generation=value optimized out) at ../Modules/gcmodule.c:865
Re: [PyQt] sip segfault in disconnectNotify
Hi, I understand that it's possible to segfault writing python code (although in my naive view this should not be the case ;)). I'm rather convinced the code is not doing anything 'illegal', but it would be helpful to have some descriptions on what exactly one can do wrong using pyqt with regard to these kind of segfaults ? I will try to write a test case for this situation, as well as for the deadlocks I mentioned earlier. Can you maybe comment on the meaning of this line in siplib.c 7288assert(PyTuple_Check(mro)); It might help me finding the cause at the python level. Thank you and best regards, Erik On Thu, 2010-09-09 at 09:06 +0100, Phil Thompson wrote: On Thu, 09 Sep 2010 09:40:43 +0200, Erik Janssens erik.janss...@conceptive.be wrote: Hello Phil, I'm experiencing a segmentation fault in sip. I have build the latest released versions of sip and pyqt on ubuntu, to be able to have a decent stack trace. The issue only arises when objects are garbage collected, so I'm unsure on how to build a simple test case for it ? When I turn the python garbage collector of (gc.disable()), the segfault never appears. If there are things I can test to acquire more information, or if somebody has ideas on how to build test cases involving the garbage collector, please let me know. Please find attached the stacktrace. There isn't a lot I can do without a test case. It is quite possible to write Python code that causes a segfault - you can't assume that it's a SIP, PyQt or Qt bug. The fact that disabling the garbage collector changes the behaviour suggests that you might not be keeping an explicit reference to something you need to. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] deadlock when using new style signal / slots
Hello Pete, it might indeed be that the deadlock is not directly related to the new style signal slot, since the deadlock might become visible due to a slight timing difference cause by eg switching to new style signal slots. however I wonder wether I'm doing anything wrong by connecting and emiting the same signal object at the same time (I did experiment with the connection type, but without result). For now I have put a mutexlock around this particular instance, but I wonder if I should mutex all possible cases ?? The camelot website (www.python-camelot.com) should be up and running, I was not aware of any downtime, it's hosted at weebly.com. The project is going well, we've put a lot of work in switching from MDI to tab based and are now converting to new style signal/slots because we noticed stability improvements by using them. These deadlocks are of course bothering me. Best regards, Erik On Mon, 2010-09-06 at 10:43 +0200, Hans-Peter Jansen wrote: Dear Erik, On Friday 27 August 2010, 21:56:14 Erik Janssens wrote: Hi, Another issue popped up when porting our code to new style signal slots. it appears the deadlock occurs when one thread is emitting using a pyqtSignal object, while another thread is connecting the same pyqtSignal object to a slot, I don't believe, that this is _directly_ related to the new style signal/slot idiom, but you might want to experiment with the connection type argument of connect. this is the pseudocode for the connection : class(...): def __init__(...): self.rsh.entity_update_signal.connect( self.handle_entity_update ) @QtCore.pyqtSlot( object, object ) def handle_entity_update( self, sender, entity ): ... Are these operations supposed to be thread safe or am I missing something ? BTW, the camelot website http://www.python-camelot.com/ seems to be down since some time.. What's the state of your project? Best regards, Pete ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] server installation of pyqt
you need to add the location of the qt DLL's to the PATH of the users (which might not be possible in a server set up), or simply copy all the DLL's to the same location as python.exe, that will do the trick. notice that having clients run pyqt apps, where the pyqt binaries are on a network share can be slow and unstable. it's best to install the binaries on the clients. On Fri, 2010-09-03 at 15:16 -0700, Suzanne Berger wrote: Hello, I would like to have PyQt4 package (Windows x64, Python 2.6x 32-bit) accessible from server for developers and users of pyqt applications. I tried copying package from local C-drive installation to location on server. That didn't work: --- sys.path.append(T:\\_library\\tools\\testPythonLib\\site-packages) from PyQt4.QtGui import * Traceback (most recent call last): File pyshell#4, line 1, in module from PyQt4.QtGui import * ImportError: DLL load failed: The specified module could not be found. --- Is it necessary to redo total install (Qt,SIP,PyQt) directly to server location? Or can portions of build be re-run? Note that I did not do original installation. I'm trying to dig out details to pass on to our IT department. Thanks in advance! Suzanne ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] new style signal/slot and sender() method
Hi, We are switching our codebase to new style signal/slot and this is a strange issue. When connecting a QComboBox currentIndexChanged signal to a slot : def granularity_changed(self, idx): granularity = self.sender().get_value() sender returns the right object, however, when using the pyqtSlot decorator : @QtCore.pyqtSlot(int) def granularity_changed(self, idx): granularity = self.sender().get_value() sender returns None. Is this a known issue ? If so, can anybody shed some light on the reasoning behind this ? Thx, Erik ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] deadlock when using new style signal / slots
Hi, Another issue popped up when porting our code to new style signal slots. it appears the deadlock occurs when one thread is emitting using a pyqtSignal object, while another thread is connecting the same pyqtSignal object to a slot, this is the pseudocode for the connection : class(...): def __init__(...): self.rsh.entity_update_signal.connect( self.handle_entity_update ) @QtCore.pyqtSlot( object, object ) def handle_entity_update( self, sender, entity ): ... Are these operations supposed to be thread safe or am I missing something ? Thanks a lot, Erik PS 1 : using pyqt 4.7.2 on Ubuntu PS 2 : stack traces A debugging session in GDB shows both threads waiting : The thread that is making the connection : #0 0x0012d422 in __kernel_vsyscall () #1 0x00138015 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x006a48c2 in QMutexPrivate::wait (this=0x8b652b0, timeout=-1) at thread/qmutex_unix.cpp:84 #3 0x006a0072 in QMutex::lock (this=0x8b63768) at thread/qmutex.cpp:205 #4 0x007b9dec in QOrderedMutexLocker::relock (sender=0x8362030, signal_index=2, receiver=0xb36795f0, method_index=27, type=0, types=0x0) at ../../include/QtCore/private/../../../src/corelib/thread/qorderedmutexlocker_p.h:82 #5 QOrderedMutexLocker (sender=0x8362030, signal_index=2, receiver=0xb36795f0, method_index=27, type=0, types=0x0) at ../../include/QtCore/private/../../../src/corelib/thread/qorderedmutexlocker_p.h:72 #6 QMetaObjectPrivate::connect (sender=0x8362030, signal_index=2, receiver=0xb36795f0, method_index=27, type=0, types=0x0) at kernel/qobject.cpp:2908 #7 0x007ba3b2 in QObject::connect (sender=0x8362030, signal=0x886dff0 2entity_update_signal(PyQt_PyObject,PyQt_PyObject), receiver=0xb36795f0, method=0xb388b018 1handle_entity_update(PyQt_PyObject,PyQt_PyObject), type=Qt::AutoConnection) at kernel/qobject.cpp:2607 #8 0x005a2f46 in ?? () from /usr/lib/pymodules/python2.6/PyQt4/QtCore.so #9 0x005a39e6 in ?? () from /usr/lib/pymodules/python2.6/PyQt4/QtCore.so #10 0x080e0a21 in call_function (f=warning: can't find linker symbol for virtual table for `(null)' value warning: can't find linker symbol for virtual table for `(null)' value Frame 0xb4cb6474, for file camelot/view/proxy/collection_proxy.py, line 228, in __init__ The thread that is emitting the signal : #1 0x0013a245 in sem_wait@@GLIBC_2.1 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0810abe8 in PyThread_acquire_lock (lock=0x8322d18, waitflag=1) at ../Python/thread_pthread.h:349 #3 0x080dbe9c in PyEval_RestoreThread (tstate=0x8878c98) at ../Python/ceval.c:353 #4 0x080fdc78 in PyGILState_Ensure () at ../Python/pystate.c:592 #5 0x005a6a06 in ?? () from /usr/lib/pymodules/python2.6/PyQt4/QtCore.so #6 0x005a295b in ?? () from /usr/lib/pymodules/python2.6/PyQt4/QtCore.so #7 0x007b23d8 in QMetaType::construct (type=256, copy=0xb6abdbc0) at kernel/qmetatype.cpp:1116 #8 0x007b91cc in queued_activate (sender=value optimized out, signal=value optimized out, c=0xba47c38, argv=0xb515ef98, semaphore=0x0) at kernel/qobject.cpp:3166 #9 0x007bb2b1 in QMetaObject::activate (sender=0x8362030, m=0x8890de8, local_signal_index=0, argv=0xb515ef98) at kernel/qobject.cpp:3266 #10 0x007bb9ea in QMetaObject::activate (sender=0x8362030, signal_index=4, argv=0xb515ef98) at kernel/qobject.cpp:3346 #11 0x007bba2b in QMetaObject::activate (sender=0x8362030, from_signal_index=4, to_signal_index=4, argv=0xb515ef98) at kernel/qobject.cpp:3204 #12 0x005a9da4 in ?? () from /usr/lib/pymodules/python2.6/PyQt4/QtCore.so #13 0x005a2aec in ?? () from /usr/lib/pymodules/python2.6/PyQt4/QtCore.so #14 0x080e0a21 in call_function (f=warning: can't find linker symbol for virtual table for `(null)' value ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] segfaults in sip getattr
Hi, I'm having segfaults in the sip getattr function. Apparently the code somewhere tries to resolve the '__dtor__' attribute. This appears to happen when a bunch of widgets get destructed. Nowhere in the code have custome __del__ or __dtor__ methods been implemented. Any idea on what is causing this or how it could be solved is more than welcome. I'm running on ubuntu 9.04 using the pyqt and qt libraries from the system. Thx, Erik (gdb) bt #0 0x0808c286 in PyObject_GenericGetAttr (obj=0x972ceec, name=0x97351e0) at ../Objects/object.c:1294 #1 0xb7f75c1e in sipWrapper_getattro (obj=0x972ceec, name=0x97351e0) at /build/buildd/sip4-qt3-4.7.9/siplib/siplib.c:7722 #2 0x0808c949 in PyObject_GetAttrString (v=0x972ceec, name=0xb7f7ea13 __dtor__) at ../Objects/object.c:1074 #3 0xb7f761e7 in sip_api_is_py_method (gil=0xb55eb1fc, pymc=0xb55eb1ec, sipSelf=0x972ceec, cname=0x0, mname=0xb7f7ea13 __dtor__) at /build/buildd/sip4-qt3-4.7.9/siplib/siplib.c:5344 #4 0xb7f76a12 in sip_api_common_dtor (sipSelf=0x972ceec) at /build/buildd/sip4-qt3-4.7.9/siplib/siplib.c:3679 #5 0xb788d191 in ~sipQGroupBox (this=0xb4be36b0) at sipQtGuipart6.cpp:9086 #6 0xb6a4fe3f in QObjectPrivate::deleteChildren (this=0xb4bcacc8) at kernel/qobject.cpp:1854 #7 0xb6cca66b in ~QWidget (this=0xb4bca9b8) at kernel/qwidget.cpp:1373 #8 0xb798145b in ~sipQWidget (this=0xb4bca9b8) at sipQtGuipart9.cpp:64250 #9 0xb6a4fe3f in QObjectPrivate::deleteChildren (this=0xb4b30320) at kernel/qobject.cpp:1854 #10 0xb6ccaddb in ~QWidget (this=0xb4b30910) at kernel/qwidget.cpp:1373 #11 0xb6a4fe3f in QObjectPrivate::deleteChildren (this=0xb4b2c800) at kernel/qobject.cpp:1854 #12 0xb6cca66b in ~QWidget (this=0xb4b44470) at kernel/qwidget.cpp:1373 #13 0xb70a9cd1 in ~QFrame (this=0xb4b44470) at widgets/qframe.cpp:243 #14 0xb7149abd in ~QAbstractScrollArea (this=0xb4b44470) at widgets/qabstractscrollarea.cpp:497 #15 0xb714f721 in ~QScrollArea (this=0xb4b44470) at widgets/qscrollarea.cpp:176 #16 0xb77bb859 in ~sipQScrollArea (this=0xb4b44470) at sipQtGuipart4.cpp:542 #17 0xb6a4fe3f in QObjectPrivate::deleteChildren (this=0xb4b79240) at kernel/qobject.cpp:1854 #18 0xb6cca66b in ~QWidget (this=0xb4bd1530) at kernel/qwidget.cpp:1373 #19 0xb70a9cd1 in ~QFrame (this=0xb4bd1530) at widgets/qframe.cpp:243 #20 0xb7113bab in ~QSplitter (this=0xb4bd1530) at widgets/qsplitter.cpp:1008 #21 0xb774cf4f in ~sipQSplitter (this=0xb4bd1530) at sipQtGuipart3.cpp:29566 #22 0xb6a4fe3f in QObjectPrivate::deleteChildren (this=0xb4b96e78) at kernel/qobject.cpp:1854 #23 0xb6cca66b in ~QWidget (this=0xb4ba8198) at kernel/qwidget.cpp:1373 #24 0xb798145b in ~sipQWidget (this=0xb4ba8198) at sipQtGuipart9.cpp:64250 #25 0xb7930f72 in release_QWidget (sipCppV=0xb4ba8198, state=262) at sipQtGuipart9.cpp:72761 #26 0xb7930fb4 in dealloc_QWidget (sipSelf=0x97351e0) at sipQtGuipart9.cpp:72775 #27 0xb7f77633 in sipWrapper_dealloc (self=0x982496c) at /build/buildd/sip4-qt3-4.7.9/siplib/siplib.c:7543 #28 0x0809ff45 in subtype_dealloc (self=0x982496c) at ../Objects/typeobject.c:709 #29 0x08088e94 in dict_dealloc (mp=0x9829f0c) at ../Objects/dictobject.c:855 #30 0xb7f729b3 in sipWrapper_clear (self=0x97285ec) at /build/buildd/sip4-qt3-4.7.9/siplib/siplib.c:7430 #31 0x080f898e in collect (generation=0) at ../Modules/gcmodule.c:713 #32 0x080f92c6 in _PyObject_GC_New (tp=0x8162000) at ../Modules/gcmodule.c:897 #33 0x08114686 in wrapperdescr_call (descr=0xb7d41d74, args=0x9720f6c, kwds=0x0) at ../Objects/descrobject.c:1058 #34 0x0805d897 in PyObject_Call (func=0x97351e0, arg=0x9720f6c, kw=0x0) at ../Objects/abstract.c:1861 #35 0x080ccd4d in PyEval_EvalFrameEx (f=0x91d28d4, throwflag=0) at ../Python/ceval.c:3823 #36 0x080cfea5 in PyEval_EvalCodeEx (co=0x8b22da0, globals=0xb7c61b54, locals=0x0, args=0x970cbf8, argcount=1, kws=0x0, kwcount=0, defs=0x8b498d8, defcount=1, closure=0x0) at ../Python/ceval.c:2875 #37 0x08117511 in function_call (func=0x8b9d844, arg=0x970cbec, kw=0x0) at ../Objects/funcobject.c:517 #38 0x0805d897 in PyObject_Call (func=0x97351e0, arg=0x970cbec, kw=0x0) at ../Objects/abstract.c:1861 #39 0x08063aaa in instancemethod_call (func=0x8b9d844, arg=0x970cbec, kw=0x0) at ../Objects/classobject.c:2519 #40 0x0805d897 in PyObject_Call (func=0x97351e0, arg=0xb7d8102c, kw=0x0) at ../Objects/abstract.c:1861 #41 0x080a6568 in slot_tp_init (self=0x96803ec, args=0xb7d8102c, kwds=0x0) at ../Objects/typeobject.c:4976 #42 0x080adac1 in type_call (type=0x8b5b9fc, args=0xb7d8102c, kwds=0x0) at ../Objects/typeobject.c:436 #43 0x0805d897 in PyObject_Call (func=0x97351e0, arg=0xb7d8102c, kw=0x0) at ../Objects/abstract.c:1861 #44 0x080ccd4d in PyEval_EvalFrameEx (f=0x9463e54, throwflag=0) at ../Python/ceval.c:3823 #45 0x080cfea5 in PyEval_EvalCodeEx (co=0x8bc14a0, globals=0x8ba0934, locals=0x0, args=0x9463e08, argcount=2, kws=0x9463e10, kwcount=0, defs=0x8bdd798, defcount=1, closure=0x0) at ../Python/ceval.c:2875 #46 0x080ce7d4 in PyEval_EvalFrameEx (f=0x9463c6c,
Re: [PyQt] random deadlocks in pyqt application
Hello Giovanni, Thanks again for your assistance. I believe I'm handling these things correctly, also there is no use of python threads in the application. I will reread those things to make sure. But we do use python's Queue module, do you think this might cause issues ? As far as I can see there is nothing in the behaviour of the application that suggests this. Regards, Erik -- Message: 2 Date: Mon, 31 Aug 2009 02:28:14 +0200 From: Giovanni Bajo ra...@develer.com Subject: Re: [PyQt] random deadlocks in pyqt application To: erik.janss...@conceptive.be Cc: PyQT mailing list pyqt@riverbankcomputing.com Message-ID: 1251678494.4741.26.ca...@ozzu Content-Type: text/plain On dom, 2009-08-30 at 11:22 +0200, Erik Janssens wrote: Hi, I'm having random deadlocks in my pyqt application (I don't do any locking and such in the app itself, but the app has 2 QThreads). They appear to occur random when the application is used like a madman (opening and closing windows all the time). A strange observation is that the chances for deadlock are higher when using xvfb instead of the normal x display. (I use this for running unittests overnight) I'm running Ubuntu 9.04 using python2.5 (the deadlocks also appear when using python2.6) The first line in the stack trace is always : xcb_wait_for_reply () from /usr/lib/libxcb.so.1 Has anybody seen this before or can give me a clue on how to proceed with this issue ? This exact segfault doesn't ring any bell to me, so I only have generic advices for you. I saw many segfaults related to the fact that the QThreads are not being used in the way that they should: http://qt.nokia.com/doc/4.5/threads.html#threads-and-qobjects Make sure that you are following all the advices in there. Also, don't use Python's threading module if you're going to touch Qt's objects. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] random deadlocks in pyqt application
Hi, I'm having random deadlocks in my pyqt application (I don't do any locking and such in the app itself, but the app has 2 QThreads). They appear to occur random when the application is used like a madman (opening and closing windows all the time). A strange observation is that the chances for deadlock are higher when using xvfb instead of the normal x display. (I use this for running unittests overnight) I'm running Ubuntu 9.04 using python2.5 (the deadlocks also appear when using python2.6) The first line in the stack trace is always : xcb_wait_for_reply () from /usr/lib/libxcb.so.1 Has anybody seen this before or can give me a clue on how to proceed with this issue ? Thx, Erik Program received signal SIGINT, Interrupt. [Switching to Thread 0xb7d8b8d0 (LWP 5820)] 0xb7f4d430 in __kernel_vsyscall () (gdb) bt #0 0xb7f4d430 in __kernel_vsyscall () #1 0xb7e687b1 in select () from /lib/tls/i686/cmov/libc.so.6 #2 0xb632fca7 in ?? () from /usr/lib/libxcb.so.1 #3 0xb6331a12 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 #4 0xb6406cae in _XReply () from /usr/lib/libX11.so.6 #5 0xb63e33b9 in XGetImage () from /usr/lib/libX11.so.6 #6 0xb68327ef in ?? () from /usr/lib/libQtGui.so.4 #7 0xb682003b in QPixmap::toImage () from /usr/lib/libQtGui.so.4 #8 0xb67e2cc3 in QWidgetPrivate::setWindowIcon_sys () from /usr/lib/libQtGui.so.4 #9 0xb67aa100 in QWidget::create () from /usr/lib/libQtGui.so.4 #10 0xb67a50c8 in QWidgetPrivate::createWinId () from /usr/lib/libQtGui.so.4 #11 0xb67e54e9 in QWidgetPrivate::setParent_sys () from /usr/lib/libQtGui.so.4 #12 0xb67ab645 in QWidget::setParent () from /usr/lib/libQtGui.so.4 #13 0xb67abe7e in QWidget::setParent () from /usr/lib/libQtGui.so.4 #14 0xb6bd77f6 in QMenuBar::setCornerWidget () from /usr/lib/libQtGui.so.4 #15 0xb6bb8937 in ?? () from /usr/lib/libQtGui.so.4 #16 0xb6bb9400 in ?? () from /usr/lib/libQtGui.so.4 #17 0xb6bc044a in ?? () from /usr/lib/libQtGui.so.4 #18 0xb6bc2425 in QMdiSubWindow::changeEvent () from /usr/lib/libQtGui.so.4 #19 0xb67a752f in QWidget::event () from /usr/lib/libQtGui.so.4 #20 0xb6bc107a in QMdiSubWindow::event () from /usr/lib/libQtGui.so.4 #21 0xb6750e9c in QApplicationPrivate::notify_helper () from /usr/lib/libQtGui.so.4 #22 0xb6759282 in QApplication::notify () from /usr/lib/libQtGui.so.4 #23 0xb7428613 in sipQApplication::notify (this=0xa1552b0, a0=0xc42d140, a1=0xbff68bb8) at sipQtGuipart9.cpp:20607 #24 0xb78a3a3b in QCoreApplication::notifyInternal () from /usr/lib/libQtCore.so.4 #25 0xb67e99e7 in QWidget::setWindowState () from /usr/lib/libQtGui.so.4 #26 0xb679c525 in QWidget::showMaximized () from /usr/lib/libQtGui.so.4 #27 0xb6bc1c1d in QMdiSubWindow::eventFilter () from /usr/lib/libQtGui.so.4 #28 0xb78a2c5a in QCoreApplicationPrivate::sendThroughObjectEventFilters () from /usr/lib/libQtCore.so.4 #29 0xb6750e7a in QApplicationPrivate::notify_helper () from /usr/lib/libQtGui.so.4 #30 0xb6759282 in QApplication::notify () from /usr/lib/libQtGui.so.4 #31 0xb7428613 in sipQApplication::notify (this=0xa1552b0, a0=0xc2b52f8, a1=0xbff69168) at sipQtGuipart9.cpp:20607 #32 0xb78a3a3b in QCoreApplication::notifyInternal () from /usr/lib/libQtCore.so.4 #33 0xb67e99e7 in QWidget::setWindowState () from /usr/lib/libQtGui.so.4 #34 0xb679c525 in QWidget::showMaximized () from /usr/lib/libQtGui.so.4 #35 0xb741060a in meth_QWidget_showMaximized (sipSelf=0xc91ab2c, sipArgs=0xb7d4b02c) at sipQtGuipart9.cpp:68687 #36 0x080ceb42 in PyEval_EvalFrameEx (f=0xa23b054, throwflag=0) at ../Python/ceval.c:3612 #37 0x080cfea5 in PyEval_EvalCodeEx (co=0xa493068, globals=0xa185604, locals=0x0, args=0xcb365b8, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2875 #38 0x08117511 in function_call (func=0xa521bc4, arg=0xcb365ac, kw=0x0) at ../Objects/funcobject.c:517 #39 0x0805d897 in PyObject_Call (func=0xbff67cac, arg=0xcb365ac, kw=0x0) at ../Objects/abstract.c:1861 #40 0x08063aaa in instancemethod_call (func=0xa521bc4, arg=0xcb365ac, kw=0x0) at ../Objects/classobject.c:2519 #41 0x0805d897 in PyObject_Call (func=0xbff67cac, arg=0xc7d394c, kw=0x0) at ../Objects/abstract.c:1861 #42 0x080c86cc in PyEval_CallObjectWithKeywords (func=0xc799644, arg=0xc7d394c, kw=0x0) at ../Python/ceval.c:3481 #43 0xb7c2fe47 in sip_api_invoke_slot (slot=0xaef1620, sigargs=0xc92772c) at /build/buildd/sip4-qt3-4.7.9/siplib/qtlib.c:716 #44 0xb79f8275 in PyQtProxy::invokeSlot (slot_co...@0xaef1618, qargs=0xbff699b8) at /build/buildd/python-qt4-4.4.4/sip/QtCore/qobject.sip:2241 #45 0xb79f8e5b in PyQtProxy::unislot (this=0xaef1608, qargs=0xbff699b8) at /build/buildd/python-qt4-4.4.4/sip/QtCore/qobject.sip:2207 #46 0xb79f8f02 in PyQtProxy::qt_metacall (this=0xaef1608, _c=QMetaObject::InvokeMetaMethod, _id=2, _a=0xbff699b8) at /build/buildd/python-qt4-4.4.4/sip/QtCore/qobject.sip:2160 #47 0xb78b9ca8 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #48 0xb78ba932 in QMetaObject::activate () from
[PyQt] Re: Re: QStyle manipulations
Message: 2 Date: Fri, 24 Jul 2009 17:56:32 -0500 From: Robert Kern robert.k...@gmail.com Subject: [PyQt] Re: QStyle manipulations To: pyqt@riverbankcomputing.com Message-ID: h4de70$pg...@ger.gmane.org Content-Type: text/plain; charset=UTF-8; format=flowed On 2009-07-24 10:26, Phil Thompson wrote: On Fri, 24 Jul 2009 01:03:47 +0200, Hans-Peter Jansenh...@urpla.net wrote: Hi, I've some layout issues with customized widgets on the Mac, and now, I would like to _intercept_ a single QStyle method: layoutSpacingImplementation(), but how? I can create a style with QtGui.QStyleFactory.create(), but how do I intercept such a method? PyQt forbids me to subclass the style object, returned from factory (Phil, shouldn't these derive from QCommonStyle, and been able to subclass? [1]) and the dirty as hell - patch it into the object - approach seem to not work either. Any more ideas? BTW, Phil, you don't wrap the style classes directly, because they may be plug-ins, but what's the technical reason behind this? Aren't there hosts of other plug-ins (sql drivers, image formats, etc..) in use today? Yes, but you don't access them directly - PyQt knows nothing about them. Do you have an answer for his main question? I am interested, too. -- Robert Kern I'd like to be able to use the dotnet style for windows users (our being able to reimplement it in python) http://labs.trolltech.com/blogs/2007/07/06/dotnet-style-with-office-flavor/ somebody has experience with this ? ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] GUI freezing when running large function in QThread
I'm doing exactly the same in our application (Validation and database access in a separate thread), and I have no issues whatsoever with the GUI still freezing. So I'm not sure either if the GIL is causing this and if you really need to spawn another process (given the additional issues this brings). But for the sake of the argument, I'd like to now as well when and when not the GIL can cause such things ? If you interface to C code within your validation, does the interface release the GIL ? Message: 4 Date: Tue, 21 Jul 2009 09:34:38 -0700 From: Brent Villalobos brent.villalo...@pdi.dreamworks.com Subject: Re: [PyQt] GUI freezing when running large function in QThread To: p...@riverbankcomputing.co.uk Message-ID: 4a65ee1e.7000...@pdi.dreamworks.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Thanks. I had a feeling that python's GIL (global interpreter lock) would be a limiting factor. I worked around my performance issue by doing some smarting caching to avoid some of the more intensive operations. But for the sake of argument, suppose I couldn't rework my algorithms. From what I can gather, is the common consensus that I need to spin off new processes? ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] model/view/delegate: data() method called too many times? Performance problem (TP)
data it is called multiple times on the same cell, but for a different role (eg : it is called once to get the text to display, and another time to get the font size). but you must make sure the data method returns very fast, because it will get called a lot, since the view itself contains no data, so each time a repaint of a cell is needed, the data method will get called. Message: 2 Date: Thu, 14 May 2009 21:21:30 +0200 From: TP paratribulati...@free.fr Subject: [PyQt] model/view/delegate: data() method called too many times? Performance problem To: pyqt@riverbankcomputing.com Message-ID: qi7ud6-rgq@rama.fbx.proxad.net Content-Type: text/plain; charset=us-ascii Hi everybody, I use model/view/delegate architecture of Qt. I have a problem of slowness in a small example given below. Run the script from a terminal to see all standard output. Try to play with the tree: expand items, click on cells, etc. You will find that the function data is called all the time by Qt. Too many times, I think. For example, we get on standard output sequences as: data, col=1, row=2 data, col=1, row=2 data, col=1, row=2 data, col=1, row=2 data, col=1, row=2 data, col=1, row=2 data, col=1, row=2 which means that the data function is called several times for the same cell! Why? It slows down a lot my real world application, which is much more complicated than this simple script. How to modify this greedy behavior of Qt? Thanks a lot Julien ## #!/usr/bin/env python # -*- coding: utf-8 -*- from PyQt4.QtCore import * from PyQt4.QtGui import * import sys class CustomProxyModel( QSortFilterProxyModel ): def filterAcceptsRow( self , source_row , source_parent_index ): return True class TreeROModel( QAbstractItemModel ): def __init__( self , parent = None ): super( TreeROModel, self ).__init__( parent ) self.root = toto self.children = [ coco , line 1 ] self.children_offirstline = [ coucou ] self.columncount = 2 def rowCount( self, parent ): node = self.nodeFromIndex( parent ) if node == self.root: return len( self.children ) elif node == coco: return 1 else: return 0 def columnCount( self, QModelIndex = None ): return 2 return self.columncount def data( self, index, role ): content = None col = index.column() row = index.row() print data, col=%i, row=%i % (col, row) if role == Qt.DisplayRole: if col == 0: content = self.nodeFromIndex( index ) elif row == 0: content = len( self.children ) - 1 else: content = nothing in this item elif role == Qt.TextAlignmentRole: if col == 0: content = int( Qt.AlignTop|Qt.AlignLeft ) else: content = int( Qt.AlignTop|Qt.AlignRight ) if content != None: return QVariant( content ) else: # default choice return QVariant() def index( self, row, column, parent_index ): parent = self.nodeFromIndex( parent_index ) if parent == coco: child = self.children_offirstline[0] else: child = self.children[ row ] index = self.createIndex( row , column , child ) return index def nodeFromIndex( self, index ): if index.isValid(): node = index.internalPointer() return node else: node = self.root return node def parent( self, child_index ): node = self.nodeFromIndex( child_index ) if node == coucou: index = self.createIndex( 0, 0, self.root ) return index else: return QModelIndex() def allIndex( self ): yield QModelIndex() index = self.createIndex( 0, 0, self.children[0] ) yield index index = self.createIndex( 0, 0, self.children_offirstline[0] ) yield index class TreeROWidget( QWidget ): def __init__( self , TreeROModel_ , title = None , parent = None ): super( TreeROWidget, self ).__init__( parent ) # central tree view self.view = QTreeView( parent ) self.view.setSelectionBehavior( QTreeView.SelectItems ) # central tree model self.model = TreeROModel_ self.proxyModel = CustomProxyModel() self.proxyModel.setSourceModel( self.model ) self.view.setModel( self.proxyModel ) self.view.setAlternatingRowColors( True ) self.connect( self.view, SIGNAL( clicked(QModelIndex) ) , self.cellClicked ) #
[PyQt] Re: faster alternative to QHeaderView's resizeToContents?
I've had similar issues. One possibility I tried was first only loading 20 rows in the table, then do the resizeToContents and only then loading the full data. That way, the columns are layout to fit those 20 rows. It works well overall, but I later have just set all the column widths according to the allowed length of the sql fields, and overruled it for some specific columns. I find the result much better. Since for large tables, it's almost impossible to get things look good for all rows. On Sat, 2009-05-09 at 09:54 +0100, pyqt-requ...@riverbankcomputing.com wrote: Re: faster alternative to QHeaderView's resizeToContents? ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] postgresql
Indeed the model/view/delegate framework is very flexible and remains snappy, even when displaying POPO's. The advantage of using an orm is that you can display properties of your objects, along with attributes. sqlalchemy / elixir is a very flexible framework that makes using complex queries easier (not easy). you could use the Camelot framework to avoid writing boilerplate code to map you python objects to tables. some screenshots are available at : http://www.conceptive.be/projects/camelot/wiki/ScreenShots 2009/3/19 Damien Elmes reso...@ichi2.net So an alternative would be to reimplement the Qsql classes using based on the Python DBAPI protocol, but maybe the cost/benefit ratio for that is too high? I'd say far to high. Qt has it own philosophy with databases, if you want snappy grids, and automatic updates and all that stuff, i'd suggest to stick to PyQt4 cplusplus-ish way of dealing with data. It's not pythoninc but it works quite well. I must admit ORM's are much more nice to work with, but SQL is not so bad. You don't need to use Qt's SQL support for snappy grids and automatic updates. Qt's model/view architecture is quite flexible and I achieve very good performance with sqlalchemy (bypassing the ORM) and a custom table model. It wasn't hard to write, either - but it is more work than using Qt's premade SQL model. ___ 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] Any Large PyQt Projects?
Hi, In my experience the big challenge with large applications with lots of computations is to keep them responsive. This is difficult in either C++ or python. I've run in a lot of difficulties in the past with a large C++ QT app. When you want your application to be multithreaded, you should design for it from the very start, it's not something you can add on later, because your design should be completely different. And because your design is so important, you should be able to quickly tryout various strategies, therefor I would recommend PyQt over QT. With regard to the GIL, it's indeed nasty, but there are workarounds, either you do your computations in C, and do the parallellisation in C as well, or use something like parallel python, which is a very decent library. OpenGL will cause the same amount of issues in pyqt as it does in qt :) Regards, Erik http://www.conceptive.be/projects/camelot/ On Thu, 2009-02-19 at 14:33 -0800, Brent Villalobos wrote: I'm looking for examples from people who have written large PyQt applications and I would like to hear your opinions on what worked well and what did not specifically with choosing python over C/C++. In particular, how does your python application handle tasks that require a lot of computation? How does it handle multiple thread performance given python's limitations on only running on one CPU (global interpreter lock)? I don't need too much detail (obviously nothing proprietary), but I just want to know if anyone has any red flags that people should be aware of before writing a large python gui app with things like openGL contexts and heavy mathematical computation? Let's make this interesting and see who has written the largest PyQt application. How many lines of code are we talking about? 10,000? 100,000? 1,000,000??? -Brent ___ 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] Mayavi, VTK and PyQt
Hello Christophe,
I once addapted the QVTKRenderWindowInteractor to work
with the latest release of pyqt. Unfortunately it's not
perfect yet and it does work only on my windows machine.
So should you make improvements to it, please post it
back.
Regards,
Erik
On Sun, 2009-02-08 at 00:57 +0100, projet...@club-internet.fr wrote:
pyqt@riverbankcomputing.com
from PyQt4 import QtCore, QtGui
import vtk
class QVTKRenderWindowInteractor(QtGui.QWidget):
A QVTKRenderWindowInteractor for Python and Qt. Uses a
vtkGenericRenderWindowInteractor to handle the interactions. Use
GetRenderWindow() to get the vtkRenderWindow. Create with the
keyword stereo=1 in order to generate a stereo-capable window.
The user interface is summarized in vtkInteractorStyle.h:
- Keypress j / Keypress t: toggle between joystick (position
sensitive) and trackball (motion sensitive) styles. In joystick
style, motion occurs continuously as long as a mouse button is
pressed. In trackball style, motion occurs when the mouse button
is pressed and the mouse pointer moves.
- Keypress c / Keypress o: toggle between camera and object
(actor) modes. In camera mode, mouse events affect the camera
position and focal point. In object mode, mouse events affect
the actor that is under the mouse pointer.
- Button 1: rotate the camera around its focal point (if camera
mode) or rotate the actor around its origin (if actor mode). The
rotation is in the direction defined from the center of the
renderer's viewport towards the mouse position. In joystick mode,
the magnitude of the rotation is determined by the distance the
mouse is from the center of the render window.
- Button 2: pan the camera (if camera mode) or translate the actor
(if object mode). In joystick mode, the direction of pan or
translation is from the center of the viewport towards the mouse
position. In trackball mode, the direction of motion is the
direction the mouse moves. (Note: with 2-button mice, pan is
defined as Shift-Button 1.)
- Button 3: zoom the camera (if camera mode) or scale the actor
(if object mode). Zoom in/increase scale if the mouse position is
in the top half of the viewport; zoom out/decrease scale if the
mouse position is in the bottom half. In joystick mode, the amount
of zoom is controlled by the distance of the mouse pointer from
the horizontal centerline of the window.
- Keypress 3: toggle the render window into and out of stereo
mode. By default, red-blue stereo pairs are created. Some systems
support Crystal Eyes LCD stereo glasses; you have to invoke
SetStereoTypeToCrystalEyes() on the rendering window. Note: to
use stereo you also need to pass a stereo=1 keyword argument to
the constructor.
- Keypress e: exit the application.
- Keypress f: fly to the picked point
- Keypress p: perform a pick operation. The render window interactor
has an internal instance of vtkCellPicker that it uses to pick.
- Keypress r: reset the camera view along the current view
direction. Centers the actors and moves the camera so that all actors
are visible.
- Keypress s: modify the representation of all actors so that they
are surfaces.
- Keypress u: invoke the user-defined function. Typically, this
keypress will bring up an interactor that you can type commands in.
- Keypress w: modify the representation of all actors so that they
are wireframe.
def __init__(self, parent=None, wflags=QtCore.Qt.WindowFlags(), **kw):
# the current button
self._ActiveButton = QtCore.Qt.NoButton
# private attributes
self.__oldFocus = None
self.__saveX = 0
self.__saveY = 0
self.__saveModifiers = QtCore.Qt.NoModifier
self.__saveButtons = QtCore.Qt.NoButton
# do special handling of some keywords:
# stereo, rw
stereo = 0
if kw.has_key('stereo'):
if kw['stereo']:
stereo = 1
rw = None
if kw.has_key('rw'):
rw = kw['rw']
# create qt-level widget
QtGui.QWidget.__init__(self, parent, wflags|QtCore.Qt.MSWindowsOwnDC)
if rw: # user-supplied render window
self._RenderWindow = rw
else:
self._RenderWindow = vtk.vtkRenderWindow()
self._RenderWindow.SetWindowInfo(str(int(self.winId(
if stereo: # stereo mode
self._RenderWindow.StereoCapableWindowOn()
self._RenderWindow.SetStereoTypeToCrystalEyes()
self._Iren = vtk.vtkGenericRenderWindowInteractor()
self._Iren.SetRenderWindow(self._RenderWindow)
# do all the necessary qt setup
self.setAttribute(QtCore.Qt.WA_OpaquePaintEvent)
self.setAttribute(QtCore.Qt.WA_PaintOnScreen)
self.setMouseTracking(True) # get all mouse events
[PyQt] Fosdem 2009
Dear all, For those of you who attend FOSDEM this year, you might be interested in the short tutorial I will present on building GUI applications with PyQt and Elixir/Sqlalchemy. more information can be found at : http://www.fosdem.org/2009/schedule/events/camelot Regards, Erik ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] segfault : interpreting back trace
Hi, I'm having a pyqt segmentation fault, and I cannot find out what is causing it. Can somebody make some suggestions on how to handle this ? I tried to use gdb to get a back trace, but it doesn't make much sense to me, it seems to be related to a c-function call, but I don't know which one (back trace below) Any help or suggestion is appreciated. regards, Erik Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb5eceb90 (LWP 17433)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x0814e1ce in PyCFunction_Call (func=0x90f5424, arg=0x8d1022c, kw=0x0) at ../Objects/methodobject.c:73 #2 0x080edfaa in call_function (pp_stack=0xb5ecc140, oparg=1) at ../Python/ceval.c:3573 #3 0x080e9623 in PyEval_EvalFrameEx (f=0x91b3544, throwflag=0) at ../Python/ceval.c:2272 #4 0x080ebc86 in PyEval_EvalCodeEx (co=0x9101e68, globals=0x90f1d54, locals=0x0, args=0x91b3518, argcount=0, kws=0x91b3518, kwcount=0, defs=0x0, defcount=0, closure=0x9068fbc) at ../Python/ceval.c:2836 #5 0x080ee4e2 in fast_function (func=0x90f3e94, pp_stack=0xb5ecc810, n=0, na=0, nk=0) at ../Python/ceval.c:3669 #6 0x080ee140 in call_function (pp_stack=0xb5ecc810, oparg=0) at ../Python/ceval.c:3594 #7 0x080e9623 in PyEval_EvalFrameEx (f=0x91b33c4, throwflag=0) at ../Python/ceval.c:2272 #8 0x080ebc86 in PyEval_EvalCodeEx (co=0x90e4b08, globals=0x905b854, locals=0x0, args=0x861598c, argcount=0, kws=0x861598c, kwcount=0, defs=0x0, defcount=0, closure=0x91139f4) at ../Python/ceval.c:2836 #9 0x080ee4e2 in fast_function (func=0x9115264, pp_stack=0xb5eccee0, n=0, na=0, nk=0) at ../Python/ceval.c:3669 #10 0x080ee140 in call_function (pp_stack=0xb5eccee0, oparg=0) at ../Python/ceval.c:3594 #11 0x080e9623 in PyEval_EvalFrameEx (f=0x8615824, throwflag=0) at ../Python/ceval.c:2272 #12 0x080ee3e5 in fast_function (func=0x8540f34, pp_stack=0xb5ecd4e0, n=1, na=1, nk=0) at ../Python/ceval.c:3659 #13 0x080ee140 in call_function (pp_stack=0xb5ecd4e0, oparg=0) at ../Python/ceval.c:3594 #14 0x080e9623 in PyEval_EvalFrameEx (f=0x8615674, throwflag=0) at ../Python/ceval.c:2272 #15 0x080ee3e5 in fast_function (func=0xb7c42124, pp_stack=0xb5ecdae0, n=1, na=1, nk=0) at ../Python/ceval.c:3659 #16 0x080ee140 in call_function (pp_stack=0xb5ecdae0, oparg=0) at ../Python/ceval.c:3594 #17 0x080e9623 in PyEval_EvalFrameEx (f=0x86154fc, throwflag=0) at ../Python/ceval.c:2272 #18 0x080ebc86 in PyEval_EvalCodeEx (co=0xb7cb4148, globals=0xb7ca6714, locals=0x0, args=0x85d22b0, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2836 #19 0x0814d90a in function_call (func=0xb7c420d4, arg=0x85d229c, kw=0x0) at ../Objects/funcobject.c:517 #20 0x08062944 in PyObject_Call (func=0xb7c420d4, arg=0x85d229c, kw=0x0) at ../Objects/abstract.c:1861 #21 0x0806bd66 in instancemethod_call (func=0xb7c420d4, arg=0x85d229c, kw=0x0) at ../Objects/classobject.c:2519 #22 0x08062944 in PyObject_Call (func=0xb7c5e9f4, arg=0xb7d47034, kw=0x0) at ../Objects/abstract.c:1861 #23 0x080ed7ba in PyEval_CallObjectWithKeywords (func=0xb7c5e9f4, arg=0xb7d47034, kw=0x0) at ../Python/ceval.c:3442 #24 0x08126311 in t_bootstrap (boot_raw=0x84a5588) at ../Modules/threadmodule.c:424 #25 0xb7f0a4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #26 0xb7e5ee5e in clone () from /lib/tls/i686/cmov/libc.so.6 (gdb) ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] commitData signal with custom delegates
Dear all,
I have created a custom editor widget together with a custom delegates,
used in a form together with a QDataWidgetMapper.
According to the documentation (and the source code confirms this), when
the editor has finished editing, the delegate should emit the commitData
signal, if this is received by the QDataWidgetMapper, this one should call
the setModelData method of the delegate.
However, this doesn't seem to work, as far as I can see, the commitData
signal is emitted, but the setModelData never gets called, please find below
the code of the delegate. The full source code is at :
http://www.conceptive.be/camelot/svn/trunk/camelot/view/controls/delegates.py
username and passwd : guest/guest
Any help or suggestion is appreciated !
Best regards,
Erik
class CodeColumnDelegate(QtGui.QItemDelegate):
def __init__(self, parts, parent=None):
super(CodeColumnDelegate, self).__init__(parent)
self.parts = parts
def createEditor(self, parent, option, index):
return editors.CodeEditor(self.parts, self, parent)
def setEditorData(self, editor, index):
value = index.data(Qt.EditRole).toPyObject()
if value:
for part_editor, part in zip(editor.part_editors, value):
part_editor.setText(unicode(part))
def setModelData(self, editor, model, index):
print 'Set model data called !!!'
from camelot.types import Code
value = []
for part in editor.part_editors:
value.append(unicode(part.text()))
model.setData(index, create_constant_function(value))
def editingFinished(self, widget):
self.emit(QtCore.SIGNAL('commitData(QWidget*)'), widget)
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
