[PyQt] QStandardItemEditorCreator missing

[Phil Thompson]

On Thu, 25 Nov 2010 22:57:42 +0100, "Hans-Peter Jansen" <hpj at urpla.net>
wrote:
> [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?

Should be fixed in tonight's snapshot.

Thanks,
Phil