Re: [PyQt] Bugs galore in QAbstractTableModel???
2010/11/28 Andreas Pakulat ap...@gmx.de: On 27.11.10 21:27:55, Ian wrote: [...] def rowCount(self, parent = None): ''' return No of rows of data. parent is a QModelIndex ''' return len(self.view) This is wrong, even for table models you have to take care to return the right number of rows depending on the parent. That means if your model gets asked for the rowCount with a valid parent, you want to return 0 (as you don't have childs under any of your rows). So check for parent.isValid(). def columnCount(self, parent = None): ''' return number of columns. parent = QModelIndex() id, name, cubref, address, town, contacts ''' return 6 Basically the same here as above, though I think this is not quite as critical. Hi Andreas, Are you sure about this? Does it mean that the example given in the page 428 of Summerfield's book is wrong? Also I find misleading the Qt documentation regarding this subject (right now I can only have a look to the Qt-6 docs). On one side the QAbstractItemModel.rowCount documentation agrees with you (or viceversa :-). But reading the Model Subclassing Reference page, section Read-only access one can see: rowCount() Provides the number of rows of data exposed by the model. These four functions must be implemented in all types of model, including list models (QAbstractListModel subclasses) and table models (QAbstractTableModel subclasses). Additionally, the following functions must be implemented in direct subclasses of QAbstractTableModel and QAbstractItemModel: columnCount() Provides the number of columns of data exposed by the model. List models do not provide this function because it is already implemented in QAbstractListModel. Sorry if I'm missing something obvious (it wouldn't be the first time that I've issues with the Qt documentation regarding models and views) Vicent -- Share what you know, learn what you don't. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] issues with webkit javascript interaction
Hi Phil, here's the next issue, this time related to webkit javascript interaction. The code is ported from Qt's webkit/formextractor example. It tries to make use of addToJavaScriptWindowObject(), which should be allow to interact with javascript code. Unfortunately, triggering submit, which should result in a call to FormExtractor.submit() isn't executed at all. python: 2.6 sip: 4.12-snapshot-ca22b358ab05 qt4: 4.7.1 pyqt4: snapshot-4.8.2-a935ffc263c2 Pete formextractor.py Description: application/python formextractor.ui Description: application/designer PYUIC = pyuic4 PYRCC = pyrcc4 UIFILES = $(wildcard *.ui) PYUIFILES = $(patsubst %.ui,ui_%.py,$(UIFILES)) RESOURCES = $(wildcard *.qrc) PYRESOURCES = $(patsubst %.qrc,%_rc.py,$(RESOURCES)) ui_%.py: %.ui $(PYUIC) -x -o $@ $ %_rc.py: %.qrc $(PYRCC) -o $@ $ all: $(PYUIFILES) $(PYRESOURCES) $(PYUIFILES): $(UIFILES) $(PYRESOURCES): $(RESOURCES) !DOCTYPE RCCRCC version=1.0 qresource fileform.html/file /qresource /RCC The Green People Book Club Welcome to The Green People Book Club. Please register to obtain a membership with us. First name: Last name: Gender: Male Female Check here if you would like to receive regular updates from us: ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Bugs galore in QAbstractTableModel???
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']))) 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? 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 -- Wolfgang ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] SIP v5 Roadmap
On lun, 2010-11-22 at 16:06 +, Phil Thompson wrote: I've added a roadmap for SIP v5 at... http://www.riverbankcomputing.com/software/sip/roadmap Comments welcome. Hi, I'm concerned by this: The code generator will be reimplemented using Python v3. It will be able to be used as a standalone application or a package. This means that users of SIP will need to install Python v3 as a dependency to run sip, even for projects using Python v2. Additional build dependencies can really really be painful to handle. I suggest you revisit this, unless you plan to make it work with Python v2 through 3to2 or similar. An alternative option would be to write it in 2to3-friendly dialect of Python v2, so that in the future when you are ready to drop Python 2 support you can simply drop the original v2 source code and use the generated version as new basis for development. -- Giovanni Bajo :: Develer S.r.l. ra...@develer.com :: http://www.develer.com Blog: http://giovanni.bajo.it Last post: Compile-time Function Execution in D ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] issues with webkit javascript interaction
On Sun, 28 Nov 2010 13:15:15 +0100, Hans-Peter Jansen h...@urpla.net wrote: Hi Phil, here's the next issue, this time related to webkit javascript interaction. The code is ported from Qt's webkit/formextractor example. It tries to make use of addToJavaScriptWindowObject(), which should be allow to interact with javascript code. Unfortunately, triggering submit, which should result in a call to FormExtractor.submit() isn't executed at all. python: 2.6 sip: 4.12-snapshot-ca22b358ab05 qt4: 4.7.1 pyqt4: snapshot-4.8.2-a935ffc263c2 Pete You just need to decorate submit() with pyqtSlot(). It will be in tonight's snapshot. Thanks, Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] SIP v5 Roadmap
On Sun, 28 Nov 2010 15:35:38 +0100, Giovanni Bajo ra...@develer.com wrote: On lun, 2010-11-22 at 16:06 +, Phil Thompson wrote: I've added a roadmap for SIP v5 at... http://www.riverbankcomputing.com/software/sip/roadmap Comments welcome. Hi, I'm concerned by this: The code generator will be reimplemented using Python v3. It will be able to be used as a standalone application or a package. This means that users of SIP will need to install Python v3 as a dependency to run sip, even for projects using Python v2. Additional build dependencies can really really be painful to handle. I suggest you revisit this, unless you plan to make it work with Python v2 through 3to2 or similar. An alternative option would be to write it in 2to3-friendly dialect of Python v2, so that in the future when you are ready to drop Python 2 support you can simply drop the original v2 source code and use the generated version as new basis for development. I don't see the dependency as a problem. There is no problem installing Python v2 and v3 side by side on Windows. Linux distros have been packaging Python v3 to run alongside v2 for some time. Phil ___ 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] More info needed on QAbstractTableModel
Hi, First - thanks to Andreas and Baz for previous help. What I need to do now is sort the rows - keeping the selected row selected. Currently if I sort, when row 6 is selected, after the sort, the new row 6 is selected. I want to have the selection move with the sorting. I have found the currentIndex and used it to save the ID of the selected row, before the sort, and it is easy to find the index of this row after the sort. How can I set the selected row to this row? Thanks Ian ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] SIP v5 Roadmap
On dom, 2010-11-28 at 15:12 +, Phil Thompson wrote: On Sun, 28 Nov 2010 15:35:38 +0100, Giovanni Bajo ra...@develer.com wrote: On lun, 2010-11-22 at 16:06 +, Phil Thompson wrote: I've added a roadmap for SIP v5 at... http://www.riverbankcomputing.com/software/sip/roadmap Comments welcome. Hi, I'm concerned by this: The code generator will be reimplemented using Python v3. It will be able to be used as a standalone application or a package. This means that users of SIP will need to install Python v3 as a dependency to run sip, even for projects using Python v2. Additional build dependencies can really really be painful to handle. I suggest you revisit this, unless you plan to make it work with Python v2 through 3to2 or similar. An alternative option would be to write it in 2to3-friendly dialect of Python v2, so that in the future when you are ready to drop Python 2 support you can simply drop the original v2 source code and use the generated version as new basis for development. I don't see the dependency as a problem. There is no problem installing Python v2 and v3 side by side on Windows. Linux distros have been packaging Python v3 to run alongside v2 for some time. Multiply that for different projects running different Python versions, requiring different SIP/PyQt versions, maybe different C++ compilers, and now different Python3 versions. Your statement is true for the simplest setups. I help people building stuff as part of my job (yes, it can be a job in itself :), and any additional dependency can cause problems, make the build system harder, and cause unnecessary slowdown in development. There are already strong dependencies between sip versions, Python versions and PyQt versions (and I'm ignoring Visual Studio issues, PyInstaller issues, build system issues, and whatnot), and I fear what might happen if we add another additional and incompatible Python version to the picture. As a concrete example, I'm working right now on an internal one-file custom build of Python bundled with sip/PyQt (+ other modules) as builtins, and a import hook to import sip modules (= they get transparently recompiled, much like pyximport does for Cython); by adding Python3 to the picture, one would need this internal Python build to ship with a Python3 within it. Now that I think of it, this might be less of a problem for me if SIP4 and SIP5 work together at the binary level. For instance, will it be possible to build PyQt4 with SIP5 and PyQwt with SIP4, and import them within the same process, pass objects back and forth, etc.? In this case, I could keep on using SIP4 wherever I feel like SIP5 would complicate build environments too much. -- Giovanni Bajo :: Develer S.r.l. ra...@develer.com :: http://www.develer.com Blog: http://giovanni.bajo.it Last post: Compile-time Function Execution in D ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] SIP v5 Roadmap
On Sun, 28 Nov 2010 18:26:58 +0100, Giovanni Bajo ra...@develer.com wrote: On dom, 2010-11-28 at 15:12 +, Phil Thompson wrote: On Sun, 28 Nov 2010 15:35:38 +0100, Giovanni Bajo ra...@develer.com wrote: On lun, 2010-11-22 at 16:06 +, Phil Thompson wrote: I've added a roadmap for SIP v5 at... http://www.riverbankcomputing.com/software/sip/roadmap Comments welcome. Hi, I'm concerned by this: The code generator will be reimplemented using Python v3. It will be able to be used as a standalone application or a package. This means that users of SIP will need to install Python v3 as a dependency to run sip, even for projects using Python v2. Additional build dependencies can really really be painful to handle. I suggest you revisit this, unless you plan to make it work with Python v2 through 3to2 or similar. An alternative option would be to write it in 2to3-friendly dialect of Python v2, so that in the future when you are ready to drop Python 2 support you can simply drop the original v2 source code and use the generated version as new basis for development. I don't see the dependency as a problem. There is no problem installing Python v2 and v3 side by side on Windows. Linux distros have been packaging Python v3 to run alongside v2 for some time. Multiply that for different projects running different Python versions, requiring different SIP/PyQt versions, maybe different C++ compilers, and now different Python3 versions. Your statement is true for the simplest setups. I help people building stuff as part of my job (yes, it can be a job in itself :), and any additional dependency can cause problems, make the build system harder, and cause unnecessary slowdown in development. There are already strong dependencies between sip versions, Python versions and PyQt versions (and I'm ignoring Visual Studio issues, PyInstaller issues, build system issues, and whatnot), and I fear what might happen if we add another additional and incompatible Python version to the picture. As a concrete example, I'm working right now on an internal one-file custom build of Python bundled with sip/PyQt (+ other modules) as builtins, and a import hook to import sip modules (= they get transparently recompiled, much like pyximport does for Cython); by adding Python3 to the picture, one would need this internal Python build to ship with a Python3 within it. Now that I think of it, this might be less of a problem for me if SIP4 and SIP5 work together at the binary level. For instance, will it be possible to build PyQt4 with SIP5 and PyQwt with SIP4, and import them within the same process, pass objects back and forth, etc.? In this case, I could keep on using SIP4 wherever I feel like SIP5 would complicate build environments too much. That would work only until SIP5 needed to bump the major number of the internal API. Of course the whole point of producing the roadmap and a migration plan for SIP4 to SIP5 is to make it easy for things like PyQwt to move from one to another in their own time. If you are suggesting that SIP5 should be implemented in Python2 rather than Python3 then you are just creating the same problem for a different sub-set of users. You are also expecting me to write new software in a dead language. I have no problem in producing a Python2 version if it turns out to be easy to do. I had no intention of supporting Python2 with dip, but it turned out to be easy to support Python v2.6 with some simple patches. However I'm not going to specify it as a requirement and I don't want people to get the impression that it will definitely happen. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] SIP v5 Roadmap
On dom, 2010-11-28 at 18:17 +, Phil Thompson wrote: On Sun, 28 Nov 2010 18:26:58 +0100, Giovanni Bajo ra...@develer.com wrote: On dom, 2010-11-28 at 15:12 +, Phil Thompson wrote: On Sun, 28 Nov 2010 15:35:38 +0100, Giovanni Bajo ra...@develer.com wrote: On lun, 2010-11-22 at 16:06 +, Phil Thompson wrote: I've added a roadmap for SIP v5 at... http://www.riverbankcomputing.com/software/sip/roadmap Comments welcome. Hi, I'm concerned by this: The code generator will be reimplemented using Python v3. It will be able to be used as a standalone application or a package. This means that users of SIP will need to install Python v3 as a dependency to run sip, even for projects using Python v2. Additional build dependencies can really really be painful to handle. I suggest you revisit this, unless you plan to make it work with Python v2 through 3to2 or similar. An alternative option would be to write it in 2to3-friendly dialect of Python v2, so that in the future when you are ready to drop Python 2 support you can simply drop the original v2 source code and use the generated version as new basis for development. I don't see the dependency as a problem. There is no problem installing Python v2 and v3 side by side on Windows. Linux distros have been packaging Python v3 to run alongside v2 for some time. Multiply that for different projects running different Python versions, requiring different SIP/PyQt versions, maybe different C++ compilers, and now different Python3 versions. Your statement is true for the simplest setups. I help people building stuff as part of my job (yes, it can be a job in itself :), and any additional dependency can cause problems, make the build system harder, and cause unnecessary slowdown in development. There are already strong dependencies between sip versions, Python versions and PyQt versions (and I'm ignoring Visual Studio issues, PyInstaller issues, build system issues, and whatnot), and I fear what might happen if we add another additional and incompatible Python version to the picture. As a concrete example, I'm working right now on an internal one-file custom build of Python bundled with sip/PyQt (+ other modules) as builtins, and a import hook to import sip modules (= they get transparently recompiled, much like pyximport does for Cython); by adding Python3 to the picture, one would need this internal Python build to ship with a Python3 within it. Now that I think of it, this might be less of a problem for me if SIP4 and SIP5 work together at the binary level. For instance, will it be possible to build PyQt4 with SIP5 and PyQwt with SIP4, and import them within the same process, pass objects back and forth, etc.? In this case, I could keep on using SIP4 wherever I feel like SIP5 would complicate build environments too much. That would work only until SIP5 needed to bump the major number of the internal API. ... and if you don't plan to support SIP4 anymore after you release SIP5. Of course the whole point of producing the roadmap and a migration plan for SIP4 to SIP5 is to make it easy for things like PyQwt to move from one to another in their own time. If you are suggesting that SIP5 should be implemented in Python2 rather than Python3 then you are just creating the same problem for a different sub-set of users. You are also expecting me to write new software in a dead language. I specifically suggested to use a 2to3-friendly dialect of Python 2, so that Python 3 users can still benefit a native version of the sip code generator; 2to3 can even be integrated in distutils, and since you are planning to use distutils for distributing sip, Python 3 users would simply have the code converted automatically under the hood for them. The same could work for you the day that you decide to drop Python 2 support from SIP and PyQt (which I hope it is not even planned right now); just run 2to3 once and commit the resulting files. Alternatively, you can write Python 3 code and run 3to2, but I've never used this tool, so I can't really back it too much. I don't know what you've done with dip and Python 2.6, but using 2to3/3to2 is usually much easier on the development than restraining yourself to a subsect of Python which is both valid Python 2 and Python 3. But it's a matter of taste, I guess. -- Giovanni Bajo :: Develer S.r.l. ra...@develer.com :: http://www.develer.com Blog: http://giovanni.bajo.it Last post: Compile-time Function Execution in D ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] embedding iconic pushButton in TableView and/or TreeView
'nuther wh!...I got a button!, lol... A button in the first column of a TreeView on startup.. Unfortunately, it's not a PushButton, so it's not pushing, lol... but surely that's something I'm overlookingbut apparently QStyleOption has no PushButton,but maybe I need to pass an argument type when declaring,... class DabDelegate(QStyledItemDelegate): def __init__(self, parent=None): super(DabDelegate, self).__init__(parent) def paint(self, painter, option, index): if index.column() == 0: # Thumbnail parent = self.parent() button = QStyleOptionButton() button.rect = option.rect QApplication.style().drawControl(QStyle.CE_PushButton, button, painter) else: QStyledItemDelegate.paint(self, painter, option, index) ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] SIP v5 Roadmap
On Sun, 28 Nov 2010 20:04:34 +0100, Giovanni Bajo ra...@develer.com wrote: On dom, 2010-11-28 at 18:17 +, Phil Thompson wrote: On Sun, 28 Nov 2010 18:26:58 +0100, Giovanni Bajo ra...@develer.com wrote: On dom, 2010-11-28 at 15:12 +, Phil Thompson wrote: On Sun, 28 Nov 2010 15:35:38 +0100, Giovanni Bajo ra...@develer.com wrote: On lun, 2010-11-22 at 16:06 +, Phil Thompson wrote: I've added a roadmap for SIP v5 at... http://www.riverbankcomputing.com/software/sip/roadmap Comments welcome. Hi, I'm concerned by this: The code generator will be reimplemented using Python v3. It will be able to be used as a standalone application or a package. This means that users of SIP will need to install Python v3 as a dependency to run sip, even for projects using Python v2. Additional build dependencies can really really be painful to handle. I suggest you revisit this, unless you plan to make it work with Python v2 through 3to2 or similar. An alternative option would be to write it in 2to3-friendly dialect of Python v2, so that in the future when you are ready to drop Python 2 support you can simply drop the original v2 source code and use the generated version as new basis for development. I don't see the dependency as a problem. There is no problem installing Python v2 and v3 side by side on Windows. Linux distros have been packaging Python v3 to run alongside v2 for some time. Multiply that for different projects running different Python versions, requiring different SIP/PyQt versions, maybe different C++ compilers, and now different Python3 versions. Your statement is true for the simplest setups. I help people building stuff as part of my job (yes, it can be a job in itself :), and any additional dependency can cause problems, make the build system harder, and cause unnecessary slowdown in development. There are already strong dependencies between sip versions, Python versions and PyQt versions (and I'm ignoring Visual Studio issues, PyInstaller issues, build system issues, and whatnot), and I fear what might happen if we add another additional and incompatible Python version to the picture. As a concrete example, I'm working right now on an internal one-file custom build of Python bundled with sip/PyQt (+ other modules) as builtins, and a import hook to import sip modules (= they get transparently recompiled, much like pyximport does for Cython); by adding Python3 to the picture, one would need this internal Python build to ship with a Python3 within it. Now that I think of it, this might be less of a problem for me if SIP4 and SIP5 work together at the binary level. For instance, will it be possible to build PyQt4 with SIP5 and PyQwt with SIP4, and import them within the same process, pass objects back and forth, etc.? In this case, I could keep on using SIP4 wherever I feel like SIP5 would complicate build environments too much. That would work only until SIP5 needed to bump the major number of the internal API. ... and if you don't plan to support SIP4 anymore after you release SIP5. I would expect to drop support some time in 2012. Of course the whole point of producing the roadmap and a migration plan for SIP4 to SIP5 is to make it easy for things like PyQwt to move from one to another in their own time. If you are suggesting that SIP5 should be implemented in Python2 rather than Python3 then you are just creating the same problem for a different sub-set of users. You are also expecting me to write new software in a dead language. I specifically suggested to use a 2to3-friendly dialect of Python 2, so that Python 3 users can still benefit a native version of the sip code generator; 2to3 can even be integrated in distutils, and since you are planning to use distutils for distributing sip, Python 3 users would simply have the code converted automatically under the hood for them. The same could work for you the day that you decide to drop Python 2 support from SIP and PyQt (which I hope it is not even planned right now); just run 2to3 once and commit the resulting files. Alternatively, you can write Python 3 code and run 3to2, but I've never used this tool, so I can't really back it too much. I don't know what you've done with dip and Python 2.6, but using 2to3/3to2 is usually much easier on the development than restraining yourself to a subsect of Python which is both valid Python 2 and Python 3. But it's a matter of taste, I guess. This is what dip needs... http://www.riverbankcomputing.com/hg/dip/.hg/patches/ I tried 2to3 briefly when porting the configure.py scripts to Python3. I wasn't impressed - it made lots of changes that weren't needed.
