Re: [PyQt] Next Releases of PyQt and SIP [Building on OS X 10.4]
On Tue, Oct 27, 2009 at 10:31 PM, Melton Low wrote: > On Wed, Oct 21, 2009 at 3:27 AM, Phil Thompson < > p...@riverbankcomputing.com> wrote: > >> On Tue, 20 Oct 2009 13:23:43 -0600, Melton Low >> wrote: >> > On Tue, Oct 20, 2009 at 11:17 AM, Phil Thompson >> > > >> wrote: >> > >> >> On Sat, 17 Oct 2009 17:31:40 -0600, Melton Low >> >> wrote: >> >> > Executing PyQt4's configure.py on Mac OS X 10.4.11 continues to >> produce >> >> > errors. >> >> > This is on a PPC Mac running OS X 10.4.11: >> >> > Python 2.6.3 >> >> > Qt 4.5.3 carbon version >> >> > Sip 4.9.1 snapshots 20091015 >> >> > PyQt4 4.6.1 snapshots 20091014 >> >> > >> >> > Configuration problem sharted with: >> >> > Qt 4.5.3 carbon version >> >> > Sip 4.9.1 snapshots 20091002 >> >> > PyQt4 4.6.1 snapshots 20091002 >> >> > >> >> > Problem disappeared if I completely removed Qt and reinstalled an >> >> > earlier >> >> > version of Qt: >> >> > Qt 4.5.2 carbon version >> >> > Sip 4.9.1 snapshots 20091001 >> >> > PyQt4 4.6.1 snapshots 20091001 >> >> > >> >> > I had posted the problem earlier. If this is being worked on, please >> >> > ignore >> >> > this. In case the new configure verbose output is useful I am >> >> > including >> >> it >> >> > as an attachment since it's quite lengthy. >> >> >> >> Have you tried configuring SIP with "--arch ppc"? >> >> >> >> Have you installed PyQt before on this system? >> >> >> >> Phil >> >> >> > >> > I have had PyQt on this system since of Qt 4.5.1. >> > >> > I tried --arch=PPC with Sip and --use_arch=PPC with PyQt the day before. >> > No >> > difference. >> >> This looks like a problem with Qt v4.5.3 where it's insisting on building >> for i386 (even if you have "CONFIG -= x86" in your .pro file). >> >> It would be interesting to compare the contents of Qt's >> mkspecs/features/mac directory with an earlier version of Qt. If they are >> different then this is what you would need to hack at. >> >> You could also try adding "CONFIG -= x86" to the top of the qtdirs.profile >> that PyQt's configure.py generates and run qmake manually on it to see if >> the "-arch i386" still appears in the Makefile. >> >> Phil >> > > Hi Phil, > > Just tried run qmake on qtdirs.mk manually with the added CONFIG line to > the top of qtdirs.pro. Please note that 'python configure.py --use-arch > ppc' did not complete but it did produce the qtdirs.pro and other qtdirs > files. > > Attached are qtdirs.pro and the output of the qmake command. The first g++ > line showed -arch i386 and -arch ppc. Your suspicion may be correct. > > Mel > Hi Phil, I just downloaded the Mac Qt sources for 4.5.2 and 4.5.3. Two files in the mkspecs/features/mac directory have changed namely default_post.prf and objective_c.prf. The results running diff are as follow: BigMac:~/Desktop/qt/qt-mac-opensource-src-4.5.2/mkspecs/features/mac melton$ diff default_post.prf ~/Desktop/qt/qt-mac-opensource-src-4.5.3/mkspecs/features/mac2a3,17 > > # Pick a suitable default architecture for qmake-based applications. > # If the Qt package contains one of x86 and x86_64, pick that one. If it > # contains both then use the compiler default. Make a similiar decision for > # PowerPC-based systems. Note that this logic assumes that Qt has been > # configured with an architecture that is usable on the system. > qt:!isEmpty(QT_CONFIG) { > contains(QMAKE_HOST.arch, ppc) { > !contains(QT_CONFIG, ppc64):contains(QT_CONFIG, ppc):CONFIG += ppc > contains(QT_CONFIG, ppc64):!contains(QT_CONFIG, ppc):CONFIG += ppc64 > } else { > !contains(QT_CONFIG, x86_64):contains(QT_CONFIG, x86):CONFIG += x86 > contains(QT_CONFIG, x86_64):!contains(QT_CONFIG, x86):CONFIG += x86_64 > } > } BigMac:~/Desktop/qt/qt-mac-opensource-src-4.5.2/mkspecs/features/mac melton$ BigMac:~/Desktop/qt/qt-mac-opensource-src-4.5.2/mkspecs/features/mac melton$ diff objective_c.prf ~/Desktop/qt/qt-mac-opensource-src-4.5.3/mkspecs/features/mac 3d2 < isEmpty(QMAKE_OBJECTIVE_CFLAGS) { #bootstrap 12c11 < } --- > BigMac:~/Desktop/qt/qt-mac-opensource-src-4.5.2/mkspecs/features/mac melton$ I have attached the two files from 4.5.2 and 4.5.3. They have been renamed so you can tell from which Qt version it came from. Hope you can figure out a fix. Mel default_post.prf.4.5.2 Description: Binary data objective_c.prf.4.5.2 Description: Binary data default_post.prf.4.5.3 Description: Binary data objective_c.prf.4.5.3 Description: Binary data ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] SIP default exception handler
On Thu, 29 Oct 2009 10:08:33 +0100, Sébastien Petitdemange wrote: > Hi, > > We are developing a C++ library that uses a single exception class > (Exception) for throwing errors. > > When wrapping the library with sip, we use the -e command line to > activate the try/catch code on each C++ call. > > However, our C++ code does not include the "throw(Exception)" modifier > on each class method, because virtually any method can throw this > exception, and it would be quite heavy to add it on every declaration. > > In this scenario, sip (v4.7.9) just include a default try {} catch (...) > { sipRaiseUnknownException }, so Python reports "Exception: Unknown". > > Is there a way to specify a default exception handler to sip, so the > generated code in this case would like something like: > > try { > // C++ call > } catch (OurDefaultException& e) { > ... > sipRaiseClassException(sipclass_OurDefaultException ... ); > } catch (...) { > sipRaiseUnknownException(); > } I've added support for a /Default/ exception annotation in tonight's snapshot. Untested - let me know if it's not quite right. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Re: Monkey-patcing virtual methods with functions: change in behaviour
On Fri, 30 Oct 2009 17:11:28 +, Phil Thompson wrote: > On Fri, 30 Oct 2009 16:43:16 +, Phil Thompson > wrote: >> On Thu, 29 Oct 2009 18:07:33 +0100, Giovanni Bajo >> wrote: >>> Hi Phil, >>> >>> it looks like SIP 4.9 changed behaviour wrt monkey-patching of virtual >>> methods. If you use a regular Python function (or a lambda) to do the >>> monkey patching, the function is passed 'self' when it's invoked. >>> >>> This change in behaviour is undocumented among the incompatibilities >>> with earlier versions. Moreover, it break existing code in a way that it >>> is hard to fix (there is no easy way to grep all occurrences); it is >>> also hard to debug because the resulting exception (eg: "function takes >>> no argument (1 given)") does not usually have any traceback attached. >>> Lastly, it does not match what Python itself does when monkey-patching a >>> method with a function; with regular Python objects, the function is not >>> passed 'self' when it's invoked as a method. >>> >>> What's your position on this? Was this change in behaviour a rationale >>> choice or just an unwanted regression? >> >> It should behave in the same way as regular Python classes do - which it >> does (both for Python v2 and v3) in my tests. >> >> Can you provide me with a test which shows different behavior? > > Ahh - hang on, just realised my test is broken... Fixed in tonight's SIP snapshot. It was fine when patching classes but behaved differently to Python when patching instances. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Re: Monkey-patcing virtual methods with functions: change in behaviour
On Fri, 30 Oct 2009 16:43:16 +, Phil Thompson wrote: > On Thu, 29 Oct 2009 18:07:33 +0100, Giovanni Bajo > wrote: >> Hi Phil, >> >> it looks like SIP 4.9 changed behaviour wrt monkey-patching of virtual >> methods. If you use a regular Python function (or a lambda) to do the >> monkey patching, the function is passed 'self' when it's invoked. >> >> This change in behaviour is undocumented among the incompatibilities >> with earlier versions. Moreover, it break existing code in a way that it >> is hard to fix (there is no easy way to grep all occurrences); it is >> also hard to debug because the resulting exception (eg: "function takes >> no argument (1 given)") does not usually have any traceback attached. >> Lastly, it does not match what Python itself does when monkey-patching a >> method with a function; with regular Python objects, the function is not >> passed 'self' when it's invoked as a method. >> >> What's your position on this? Was this change in behaviour a rationale >> choice or just an unwanted regression? > > It should behave in the same way as regular Python classes do - which it > does (both for Python v2 and v3) in my tests. > > Can you provide me with a test which shows different behavior? Ahh - hang on, just realised my test is broken... Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Re: Monkey-patcing virtual methods with functions: change in behaviour
On Thu, 29 Oct 2009 18:07:33 +0100, Giovanni Bajo wrote: > Hi Phil, > > it looks like SIP 4.9 changed behaviour wrt monkey-patching of virtual > methods. If you use a regular Python function (or a lambda) to do the > monkey patching, the function is passed 'self' when it's invoked. > > This change in behaviour is undocumented among the incompatibilities > with earlier versions. Moreover, it break existing code in a way that it > is hard to fix (there is no easy way to grep all occurrences); it is > also hard to debug because the resulting exception (eg: "function takes > no argument (1 given)") does not usually have any traceback attached. > Lastly, it does not match what Python itself does when monkey-patching a > method with a function; with regular Python objects, the function is not > passed 'self' when it's invoked as a method. > > What's your position on this? Was this change in behaviour a rationale > choice or just an unwanted regression? It should behave in the same way as regular Python classes do - which it does (both for Python v2 and v3) in my tests. Can you provide me with a test which shows different behavior? Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] QGraphicsView rubberband selection
On Fri, Oct 30, 2009 at 3:40 PM, Antonio Valentino < antonio.valent...@tiscali.it> wrote: > Debian sid > > Qt 4.5.3 > PyQt4 4.6-1 > Fedora 8 Qt 4.4.3 PyQt4 4.2 -- Alex Borghgraef ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] QGraphicsView rubberband selection
Il giorno Fri, 30 Oct 2009 15:19:25 +0100 Alexander Borghgraef ha scritto: > On Fri, Oct 30, 2009 at 2:50 PM, Antonio Valentino < > antonio.valent...@tiscali.it> wrote: > > > > > > > Try to install the event filter in the scene > > > > self.gs.installEventFilter(self) > > > > and then > > > >if event.type() == QEvent.GraphicsSceneMouseRelease: > >self.p0 = event.buttonDownScenePos(Qt.LeftButton) > >self.p1 = event.scenePos() > > > > > > This should work for every view attached to the scene. > > > > To hold the selection one could add a rectangle in a "special" > > GraphicsItemGroup. > > > > > > > For the other readers, I'm still interested in how to get to the > > > QGraphicsView's rubberband selection data, as I think that would > > > be the most elegant solution. > > > > > > ciao > > > > -- > > Antonio Valentino > > > > Hmm, this gives me an error: > > > AttributeError: buttonDownScenePos > > > > Debian sid Qt 4.5.3 PyQt4 4.6-1 -- Antonio Valentino ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] QGraphicsView rubberband selection
On Fri, Oct 30, 2009 at 2:50 PM, Antonio Valentino < antonio.valent...@tiscali.it> wrote: > > > Try to install the event filter in the scene > > self.gs.installEventFilter(self) > > and then > >if event.type() == QEvent.GraphicsSceneMouseRelease: >self.p0 = event.buttonDownScenePos(Qt.LeftButton) >self.p1 = event.scenePos() > > > This should work for every view attached to the scene. > > To hold the selection one could add a rectangle in a "special" > GraphicsItemGroup. > > > > For the other readers, I'm still interested in how to get to the > > QGraphicsView's rubberband selection data, as I think that would be > > the most elegant solution. > > > ciao > > -- > Antonio Valentino > Hmm, this gives me an error: > AttributeError: buttonDownScenePos > -- Alex Borghgraef ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] QGraphicsView rubberband selection
Hi Alexander, Il giorno Fri, 30 Oct 2009 11:44:31 +0100 Alexander Borghgraef ha scritto: > On Fri, Oct 30, 2009 at 9:44 AM, Antonio Valentino < > antonio.valent...@tiscali.it> wrote: > > > > > I have the same problem. At the moment I have a solution based on > > event filters but I'm very interested in a solution exploiting > > built-in features so please keep updated. > > > > Interesting to see that I'm not alone in this :-) I tried looking > into event filters, but I don't grasp how they work yet. I tried the > following code to capture the selection position, but it doesn't > behave like I expected, maybe you can shed some light on this? > > class Dialog(QWidget): > > def __init__(self, parent=None): > > QWidget.__init__(self, parent) > > self.gs = QGraphicsScene() > > self.gv = QGraphicsView(self.gs) > > self.gv.installEventFilter(self) > > self.gv.show() > > > > def eventFilter(self, object, event): > > if event.type() == QEvent.MouseButtonPress: > > self.p0 = self.mapFromGlobal(event.globalPos()) > > return True > > elif event.type() == QEvent.MouseButtonRelease: > > self.p1 = self.mapFromGlobal(event.globalPos()) > > return True > > else: > > return False > > > > So I attach the eventfilter to the QGraphicsView instance, and > capture the position at the mouse button press and release. When I > print p0 and p1, only p0 (the button press one) responds, the release > does nothing. Any ideas why? Try to install the event filter in the scene self.gs.installEventFilter(self) and then if event.type() == QEvent.GraphicsSceneMouseRelease: self.p0 = event.buttonDownScenePos(Qt.LeftButton) self.p1 = event.scenePos() This should work for every view attached to the scene. To hold the selection one could add a rectangle in a "special" GraphicsItemGroup. > For the other readers, I'm still interested in how to get to the > QGraphicsView's rubberband selection data, as I think that would be > the most elegant solution. ciao -- Antonio Valentino ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Cannot import QtWebKit
I'm using PyQt-x11-gpl-4.7-snapshot-20091028.tar.gz and this fails: Python 2.6.4 (r264:75706, Oct 29 2009, 15:38:25) [GCC 4.4.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from PyQt4 import QtWebKit Traceback (most recent call last): File "", line 1, in ImportError: cannot import name QtWebKit PyQt was built against Qt 4.6.0. I ran configure.py without any additional arguments. The C++ WebKit seems to be installed correctly since Arora works fine with it. -- View this message in context: http://old.nabble.com/Cannot-import-QtWebKit-tp26130346p26130346.html Sent from the PyQt mailing list archive at Nabble.com. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] QGraphicsView rubberband selection
On Fri, Oct 30, 2009 at 9:44 AM, Antonio Valentino < antonio.valent...@tiscali.it> wrote: > > I have the same problem. At the moment I have a solution based on > event filters but I'm very interested in a solution exploiting built-in > features so please keep updated. > Interesting to see that I'm not alone in this :-) I tried looking into event filters, but I don't grasp how they work yet. I tried the following code to capture the selection position, but it doesn't behave like I expected, maybe you can shed some light on this? class Dialog(QWidget): > def __init__(self, parent=None): > QWidget.__init__(self, parent) > self.gs = QGraphicsScene() > self.gv = QGraphicsView(self.gs) > self.gv.installEventFilter(self) > self.gv.show() > > def eventFilter(self, object, event): > if event.type() == QEvent.MouseButtonPress: > self.p0 = self.mapFromGlobal(event.globalPos()) return True > elif event.type() == QEvent.MouseButtonRelease: > self.p1 = self.mapFromGlobal(event.globalPos()) > return True > else: > return False > So I attach the eventfilter to the QGraphicsView instance, and capture the position at the mouse button press and release. When I print p0 and p1, only p0 (the button press one) responds, the release does nothing. Any ideas why? For the other readers, I'm still interested in how to get to the QGraphicsView's rubberband selection data, as I think that would be the most elegant solution. -- Alex Borghgraef ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] QGraphicsView rubberband selection
Hi Alexander, Il giorno Thu, 29 Oct 2009 16:53:04 +0100 Alexander Borghgraef ha scritto: > Hi all, > > > I've been writing an app which displays sequences of images, and > allows for the selection of regions of interest in them. > Display/playback works like a charm, basically I use a > QGraphicsScene/View setup with a QGraphicsPixmapItem in the scene, > which is then updated upon receiving the timeout signal of a timer. > Pretty basic stuff. > > Now for selection: one approach would be to subclass either the > QGraphicsView or the QGraphicsPixmapItem, overload the mouse > events, get the selection coordinates from that for further use and > put a QGraphicsRectItem on the scene on top of the selection. Yes, one solution is subclassing, another could be using eventFilter(s). > Now, I noticed that QGraphicsView already has rubberband selection > implemented: when I set the View's DragMode to > QGraphicsView.RubberBandDrag, I get a nice rubberband rectangle when > I drag the mouse across the View. My problem here is > that I can't seem to figure out how to access the selection > coordinates of that rectangle. Is there some way of accessing this > data? There doesn't seem to be any getDragSelection( ) or some such > function, but then how does this work? Do I need to get it from the > underlying QGraphicsScene object? Help would be appreciated. I have the same problem. At the moment I have a solution based on event filters but I'm very interested in a solution exploiting built-in features so please keep updated. Best regards -- Antonio Valentino ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Block for interactions
I have a widget with a start button. When the start button is pressed the cursor changes to a WaitCursor (hour-glass shaped cursor). In the same instant, I want all user-interaction with the widget to be blocked. That is, the widget should change to the same state it has when being blocked by a modal dialog. Is this just calling setEnabled(False) or is there some more specific method? A blocked widget look different from a disabled widget. Best regards, Mads -- +-+ | Mads Ipsen, Scientific developer| +---+-+ | QuantumWise A/S | phone: +45-29716388 | | Nørre Søgade 27A | www:www.quantumwise.com | | DK-1370 Copenhagen K, Denmark | email: m...@quantumwise.com | +---+-+ ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt