[PyQt] QStandardItemEditorCreator missing

Hans-Peter Jansen hpj at urpla.net
Thu Nov 25 21:57:42 GMT 2010


[Missed to addressed you directly the last time, sorry]

On Thursday 25 November 2010, 18:23:38 Hans-Peter Jansen wrote:
> On Thursday 25 November 2010, 14:44:33 Phil Thompson wrote:
> > On Thu, 25 Nov 2010 14:26:50 +0100, "Hans-Peter Jansen"
> > <hpj at urpla.net>
> >
> > wrote:
> > > On Thursday 25 November 2010, 13:27:00 Phil Thompson wrote:
> > >> On Thu, 25 Nov 2010 13:11:13 +0100, "Hans-Peter Jansen"
> > >> <hpj at urpla.net>
> > >>
> > >> wrote:
> > >> > Hi Phil,
> > >> >
> > >> > attached is an attempt to port the coloreditorfactory example
> > >> > to PyQt. This reveals a few issues, though.
> > >> >
> > >> > the most prominent thing, that stands out, is that
> > >> > QStandardItemEditorCreator is missing. This wouldn't harm as
> > >> > such, if I would be able to wrap my mind around PyQt's Qt
> > >> > property support, although it would make the task more
> > >> > convenient being able to subclass from the widget in question
> > >> > instead of
> > >> > QItemEditorCreatorBase.
> > >>
> > >> It's not supported because it is a template class.
> > >>
> > >> > This revealed another question: basing a custom item delegate
> > >> > editor on QItemEditorCreatorBase takes defining a Q_PROPERTY
> > >> > with a USER keyword. How could this be archived with PyQt? You
> > >> > mention the support of Qt properties by keyword. But how does
> > >> > this map to the READ/WRITE/WHATEVER pattern of Q_PROPERTY
> > >> > macros?
> > >>
> > >> Use pyqtProperty().
> > >
> > > Sorry for being dense, but I still don't get how to set a USER
> > > property.
> > >
> > > IOW: create a property with the USER flag set to True as
> > > described here:
> > >
> > > 	QMetaObject::userProperty()
> > >
> > >>> from PyQt4.QtCore import pyqtProperty
> > >>> help(pyqtProperty)
>
> Duuh, silly me. Thanks for the reminder.
>
> Unfortunately, it's still not behaving right: the color chooser is
> created and shown correctly on double click, one can choose another
> value, but that isn't supplied back into the table correctly,
> although the property getter _is_ called and given the new value.
>
> What am I missing?

Okay, the issue is related to QVariant vs. QColor handling. Attached are
two examples using both QVariant APIs with some debug prints added.

If you run the scripts, and press "Arrow left", "blank", "Arrow down", 
"Return", "Return", something similar the following is printed: 

ColorListEditor.setColor(#f0f8ff) <PyQt4.QtGui.QColor object at 0xb567fdf4> True
item0: <PyQt4.QtGui.QColor object at 0xb567fd84> #f0f8ff
item1: <PyQt4.QtGui.QColor object at 0xb567fdbc> #faebd7
current index 0
found index: 0
ColorListEditor.getColor(): #faebd7 <PyQt4.QtGui.QColor object at 0xb567fdf4>
ColorListEditor.setColor(#000000) <PyQt4.QtGui.QColor object at 0xb567fdf4> False
item0: <PyQt4.QtGui.QColor object at 0xb567fdbc> #f0f8ff
item1: <PyQt4.QtGui.QColor object at 0xb567fd84> #faebd7
current index 1
found index: -1
invalid index

no matter, which QVariant API is used. For some reason, the QColor instance
is damaged between the first getColor() call (after selecting the second item), 
and the following setColor() call.

This raises the question, what happened to this QColor instance between these 
calls?

Pete
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coloreditorfactory-qvariant.py
Type: application/x-python
Size: 3551 bytes
Desc: not available
URL: <http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20101125/8a16b729/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coloreditorfactory.py
Type: application/x-python
Size: 3701 bytes
Desc: not available
URL: <http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20101125/8a16b729/attachment-0003.bin>


More information about the PyQt mailing list