[PyQt] QStandardItemEditorCreator missing

[Hans-Peter Jansen]

On Friday 26 November 2010, 15:15:32 Phil Thompson wrote:
> 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.

Cool, thanks. Could you point me to the fix? Is it in sip, or PyQt?

Pete