Re: [PyQt] ANN: PyQt v4.8.2 Released
On Sun, Dec 26, 2010 at 2:25 PM, Knacktus knack...@googlemail.com wrote:
Am 24.12.2010 13:49, schrieb Phil Thompson:
PyQt v4.8.2 has been released.
This is primarily a bug fix release but also includes a number of new
examples from Hans-Peter Jansen.
For the first time 64-bit Windows installers are provided.
Awesome! Thank you Santa ;-)
I echo the appreciation for the 64-bit Windows installers.
Since I've got both the x86 and x64 PyQt4 packages installed on my
system, both of them are listed in %PATH%. py2exe seems to be
supremely confused by this and will always pick up Qt*.dll from the
first PyQt4/bin folder in the path. So I've had to add logic like
below to my installer build scripts to remove these extra folders from
the PATH if they are not within the current Python interpreter's exec
prefix.
path = installenv.get('PATH', '').split(os.pathsep)
deletions = []
for dir in path:
if dir.endswith(r'Lib\site-packages\PyQt4\bin') and \
not dir.startswith(sys.exec_prefix):
deletions.append(dir)
for dir in deletions:
path.remove(dir)
PS: If any list members use Mercurial, the PyQt port of TortoiseHg can
be found at: https://bitbucket.org/tortoisehg/thg/downloads
--
Steve Borho
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Bugs galore in QAbstractTableModel???
On Mon, Nov 29, 2010 at 4:35 AM, Wolfgang Rohdewald wolfg...@rohdewald.de wrote: On Sonntag 28 November 2010, Steve Borho wrote: Indeed, I found these when I started using the file, and checked in a fixed version here: http://bitbucket.org/tortoisehg/thg/src/tip/tortoisehg/hgqt/mo deltest.py here are some more bug fixes for editable models. The patch is against your file. I changed the alignment checks to match http://qt.gitorious.org/qt/qt/blobs/4.7/tests/auto/modeltest/modeltest.cpp Thanks. http://bitbucket.org/tortoisehg/thg/changeset/c8b88546b90e -- Steve Borho ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Bugs galore in QAbstractTableModel???
On Sun, Nov 28, 2010 at 8:18 AM, Wolfgang Rohdewald wolfg...@rohdewald.de wrote: On Sonntag 28 November 2010, Steve Borho wrote: I found an updated version of the file here: http://bazaar.launchpad.net/~bzr/ubuntu/maverick/qbzr/bzr-ppa/ annotate/head:/lib/tests/modeltest.py this still needs more updates. Mostly for editable models. Like - c = insert.pop() + c = self.insert.pop() or - assert(c['last'] == self.model.data(model.index(start-1, 0, c['parent']))) + assert(c['last'] == self.model.data(self.model.index(start-1, 0, c['parent']))) Indeed, I found these when I started using the file, and checked in a fixed version here: http://bitbucket.org/tortoisehg/thg/src/tip/tortoisehg/hgqt/modeltest.py also, the alignment test around line 289 seem to be too strict. Qt.alignLeft|Qt.alignTop does actually align at top (try with a row containing a check box), so why should it be invalid? Didn't catch that one. I am working on making my models bug free by using modeltest (although they do work fine as they are) - when done I will publish my new modeltest.py Excellent. -- Steve Borho ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] x64 Windows packages
Is there any plan to make x64 Windows packages available for download? I found a package at: http://www.lfd.uci.edu/~gohlke/pythonlibs/ and have built functional x64 installers with it, but their package is a bit old. -- Steve Borho ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Bugs galore in QAbstractTableModel???
On Sat, Nov 27, 2010 at 9:42 PM, Baz Walter baz...@ftml.net wrote: On 27/11/10 23:02, Ian wrote: On 27/11/2010 22:23, Baz Walter wrote: the python version andreas is referring to is modeltest.py. it can be found in the pyqt source in the contrib/pymodeltest directory. I found the version I think I need (4.7.4) at http://python-qt4.sourcearchive.com/documentation/4.7.4-0ubuntu1/modeltest_8py-source.html I have been unable to find out how to run it - so guessing I tried this. that link doesn't show all of the contents of the source - it's missing the README file. here's the relevant part: quote To Use the model test do the following: 1) Include the modeltest.py file in your project directory 2) Then in your source import modeltest and instantiate ModelTest with your model so the test can live for the lifetime of your model. For example: from modeltest import ModelTest self.model = QDirModel(self) self.modeltest = ModelTest(self.model, self) 3) That is it. When the test finds a problem it will throw an AssertionError. modeltest.py contains some hints on how to fix problems that the test finds. /quote ___ PyQt mailing list p...@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt I found an updated version of the file here: http://bazaar.launchpad.net/~bzr/ubuntu/maverick/qbzr/bzr-ppa/annotate/head:/lib/tests/modeltest.py -- Steve Borho ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Advice for thread/process output logging, Windows debugging
On Thu, Sep 16, 2010 at 3:15 PM, Erik Janssens erik.janss...@conceptive.be wrote: 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. I was unable to force the crash to occur on other platforms by adding gc.collect() statements in as many places as I thought might be interesting. It remains a Windows only crash, and after some recent cleanups of the threading code, it has become harder to reproduce at all, except on one slow machine of mine. Another developer submitted this patch (which connects our QDialog derived dialog's finished signal to it's deleteLater slot): http://bitbucket.org/tortoisehg/thg/changeset/f71b8c174e9f And it does indeed appear to make the crash un-reproducable.. I did 20 updates back-to-back without any hitches. Which begs the question: What is the canonical way to handle modal dialogs with PyQt4 today? Should we do explicit cleanup like this? -- Steve Borho ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Advice for thread/process output logging, Windows debugging
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? -- Steve Borho [1] http://bitbucket.org/tortoisehg/thg/src/tip/tortoisehg/hgqt/thread.py ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Howto use the Qt documentation successfully - Was: Re: Access to lines of text on textEdit.
On Tue, Sep 14, 2010 at 4:08 AM, Hans-Peter Jansen h...@urpla.net wrote: On Tuesday 14 September 2010, 09:48:47 Algis Kabaila wrote: On Tuesday 14 September 2010, 01:54:01 Algis Kabaila wrote: Is it possible to access lines of text in a textEdit? If so how can I find information about it? On Tuesday 14 September 2010 10:09:10 Hans-Peter Jansen wrote: Depending on document type, try this: document().findBlockByLineNumber(lineNumber).text() Pete On Tuesday 14 September 2010 12:24:52 Henning Schröder wrote: If you enter findBlockByLineNumber in Qt Assistant you will see that this method belongs to a QTextDocument object and returns a QTextBlock object QTextEdit has a method called document() which returns a QTextDocument. Henning In summary, the i-th line is returned by the following line = self.textEdit.document().findBlockByLineNumber(i).text(), which at least in part is identical to what Hans-Peter told me to do. Hennings advice to look up Qt Assistant was an invaluable help. Thank you both. Al, I cannot imagine how to work with PyQt successfully _without_ using assistant. Of course, Qt's class hierarchy is quite senseful most of the time in the first place, but due to the sheer volume of it, nobody is able to memorize this all. Just a few words on methology: Searching for some functionality of QTextEdit, e.g. how to get at a specific line via line number: * Look up QTextEdit in assistant We read: The QTextEdit class provides a widget that is used to edit and display both plain and rich text. * Click on more... We read: QTextEdit works on paragraphs and characters. A paragraph is a formatted string which is word-wrapped to fit into the width of the widget. By default when reading plain text, one newline signifies a paragraph. Sounds like we're looking for paragraphs in plain text mode * Check class methods, that do what we want: Nothing obvious stands out * Check base classes: QTextEdit inherits from QAbstractScrollArea only, that won't help us much here * Check methods again: Nothing obvious with paragraphs, but QTextDocument * document() might be interesting * Click on document() method: We read: Returns a pointer to the underlying document. * Check it out: click on QTextDocument We read: The QTextDocument class holds formatted text that can be viewed and edited using a QTextEdit We're getting nearer, but still no ball: check out class methods * It has a method: QTextBlock findBlockByLineNumber ( int lineNumber ) Sounds like the best fit: click on method * We read: Returns the text block that contains the specified lineNumber. What the hell is a QTextBlock? Click: It encapsulates text fragments, and provides access to them * Check methods: QString text() sounds, like what we are looking for We read: Returns the block's contents as plain text. Target reached. Note, how this transforms to a single line of code. Isn't it impressive, how much power is at our finger tips and how much joy it can be to ignore all this superfluous C++ decoration, that would involve much more work to get right ;-) How does one get the documentation files to make assistant useful on Windows? -- Steve Borho ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] generic exception handler
Is there a way to register a generic exception handler with PyQt to catch errors that happen in signal handlers? I use a Python library that emits 3-4 exceptions somewhat randomly for some fairly common error conditions, and it would be nice to handle them all in one place. Cheers. -- Steve Borho ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] generic exception handler
On Thu, Aug 19, 2010 at 11:16 AM, Jeremy Sanders jer...@jeremysanders.net wrote: Steve Borho wrote: Is there a way to register a generic exception handler with PyQt to catch errors that happen in signal handlers? I use a Python library that emits 3-4 exceptions somewhat randomly for some fairly common error conditions, and it would be nice to handle them all in one place. You probably want sys.excepthook - see http://svn.gna.org/viewcvs/veusz/trunk/veusz_main.py?rev=1141view=markup for an example of catching exceptions to bring up a dialog. Thanks, that looks interesting, but I meant PyQt signal handlers not the POSIX variety. -- Steve Borho ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] generic exception handler
On Thu, Aug 19, 2010 at 12:14 PM, Steve Borho st...@borho.org wrote: On Thu, Aug 19, 2010 at 11:16 AM, Jeremy Sanders jer...@jeremysanders.net wrote: Steve Borho wrote: Is there a way to register a generic exception handler with PyQt to catch errors that happen in signal handlers? I use a Python library that emits 3-4 exceptions somewhat randomly for some fairly common error conditions, and it would be nice to handle them all in one place. You probably want sys.excepthook - see http://svn.gna.org/viewcvs/veusz/trunk/veusz_main.py?rev=1141view=markup for an example of catching exceptions to bring up a dialog. Thanks, that looks interesting, but I meant PyQt signal handlers not the POSIX variety. Sorry, I was too quick to dismiss. This does get called when any unhandled exception occurs, which is what I need. -- Steve Borho ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] generic exception handler
On Thu, Aug 19, 2010 at 12:50 PM, Sybren A. Stüvel syb...@stuvel.eu wrote: On Thu, Aug 19, 2010 at 12:31:36PM -0500, Steve Borho wrote: Sorry, I was too quick to dismiss. This does get called when any unhandled exception occurs, which is what I need. Be aware that sys.excepthook is called from the thread that causes the exception. I streamlined this by emitting a Qt signal from the exception handler, and showing a dialog box from a connected slot in the GUI thread. That would explain the crash I see when I first tried to use it. Excellent, thanks. -- Steve Borho ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] RE : Re: DLL Problem with PyQt-Py3.1-gpl-4.7.3-1.exe
On Fri, Jun 18, 2010 at 11:07 AM, Eric Coetzee ericcoet...@gmail.com wrote: I don't see any further messages in this thread, so I assume that 2.6.5 works for all using PyQt 4.7.3. I still have a problem though: Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on win32 Type copyright, credits or license for more information. from PyQt4.QtCore import * Traceback (most recent call last): File console, line 0, in module ImportError: DLL load failed: The specified procedure could not be found. The only difference I can see is that I run a commercial version of PyQt: i.e. PyQt-win-commercial-4.7.3 I've had similar problems before. Uninstalling and re-installing PyQt has always resolved them. It's a rather brutal workaround, but I couldn't figured out what the root cause was. Note that PyQt requires a folder inside your Python site-packages to be in the PATH in order for it to work on Windows. -- Steve Borho ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Performance problems with QSortFilterProxyModel
On Tue, May 11, 2010 at 8:33 PM, Steve Borho st...@borho.org wrote: Hello, The TortoiseHg project is currently porting all of our PyGTK apps to PyQt, This has been going pretty well so far, but I've hit a snag with our file status browser. I have a simple QAbstractTableModel (4 columns) being displayed in a QTreeView. After connecting a QSortFilterProxyModel between the tree view and the data model, reloading the model became very expensive for moderately sized data sets. After calling setSourceModel() with a model of 555 rows, I counted over 3 million calls to the model data() method, which takes about 15 seconds. I googled around and found some complaints that resizeColumnToContents() was expensive when the sort filter was in use, and I confirmed that in our case (using simple print profiling). However, removing the resize statements only moves the performance hit till later on. I can only guess the sort model is waiting for it's first access to perform the initial sort. I'm pretty sure I could implement the simple sorting and filtering we need in our data model, but before I do I thought I'd ask here if there was some common problem that could cause this performance hit. This kind of smells like the kind of problem caused by not disabling a signal while you do certain operations. Another TortoiseHg developer has developed a patch that vastly improved the performance of the proxy model sort. It's still not as fast has implementing the sort ourselves, so we'll not be going back to it, but I thought I would post the fix here for posterity. The patch applies to our QAbstractTableModel derived class. def rowCount(self, parent): +if parent.isValid(): +return 0 # no child return len(self.rows) def columnCount(self, parent): +if parent.isValid(): +return 0 # no child return len(self.headers) I hope that helps someone else. -- Steve Borho ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Performance problems with QSortFilterProxyModel
On Thu, May 13, 2010 at 5:01 AM, Mark Summerfield l...@qtrac.plus.com wrote: On 2010-05-12, Steve Borho wrote: On Wed, May 12, 2010 at 1:04 AM, Mark Summerfield l...@qtrac.plus.com wrote: On 2010-05-12, Steve Borho wrote: Hello, The TortoiseHg project is currently porting all of our PyGTK apps to PyQt, This has been going pretty well so far, but I've hit a snag with our file status browser. I have a simple QAbstractTableModel (4 columns) being displayed in a QTreeView. After connecting a QSortFilterProxyModel between the tree view and the data model, reloading the model became very expensive for moderately sized data sets. After calling setSourceModel() with a model of 555 rows, I counted over 3 million calls to the model data() method, which takes about 15 seconds. Have you tried switching off sorting just before resetting the model and then switching it back on afterwards? I just tried with this: tm = MyTableModel(data) tv.setSortingEnabled(False) proxy.setSourceModel(tm) tv.setSortingEnabled(True) But it made no performance difference. Then maybe no sorting took place? When you call QAbstractTableView.setSortingEnabled(True), Qt is supposed to call QAbstractTableView.sortByColumn() to perform the sort. But sortByColumn() will only have an effect if the model is sortable, that is, if the QAbsractItemModel you're using has reimplemented the sort() method (since the base class version does nothing). Things are slightly different if you use a QSortFilterProxyModel of course, since that provides an implementation of QAbsractItemModel.sort(). So in the example you've shown the proxy should do the sorting. But I guess you're saying yes it sorted---but it was just as slow? However, you don't mention where the model gets set on the view? Does this make a difference: # tv has no model at this point tm = MyTableModel(data) tv.setSortingEnabled(False) proxy.setSourceModel(tm) tv.setModel(proxy) # now tv has a model tv.setSortingEnabled(True) I did just try this and it had no effect on the performance. As soon as control is returned to the main event loop, it performs millions of model.data() calls. Using QSortFilterProxyModel can adversely affect performance. So one solution is to try to avoid using it, i.e., by reimplementing the sort() method in your custom QAbstractTableModel. This was what I ended up doing. It was actually pretty painless. Another solution is to get the correct ordering without sorting at all by using intrinsically ordered data structures. The sort itself is pretty fast now; but I did re-order a few lines to make sure the sort is only performed once when a model is first created. -- Steve Borho ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Performance problems with QSortFilterProxyModel
On Wed, May 12, 2010 at 1:04 AM, Mark Summerfield l...@qtrac.plus.com wrote: On 2010-05-12, Steve Borho wrote: Hello, The TortoiseHg project is currently porting all of our PyGTK apps to PyQt, This has been going pretty well so far, but I've hit a snag with our file status browser. I have a simple QAbstractTableModel (4 columns) being displayed in a QTreeView. After connecting a QSortFilterProxyModel between the tree view and the data model, reloading the model became very expensive for moderately sized data sets. After calling setSourceModel() with a model of 555 rows, I counted over 3 million calls to the model data() method, which takes about 15 seconds. Have you tried switching off sorting just before resetting the model and then switching it back on afterwards? I just tried with this: tm = MyTableModel(data) tv.setSortingEnabled(False) proxy.setSourceModel(tm) tv.setSortingEnabled(True) But it made no performance difference. -- Steve Borho ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
