[PyQt] pyuic expects certain property methods in Designer plugins

[Arve Knudsen]

What's the meaning of the stdset attribute? It turns out that for the
properties of my own custom widget Designer does not specify the stdset
attribute (not quite sure why), and if stdset is missing or equals "1" pyuic
reverts to the old behaviour of guessing the setter method's name (rather
than using setProperty).

Arve

On 10/7/07, Arve Knudsen <arve.knudsen at gmail.com> wrote:
>
> On 10/6/07, Phil Thompson <phil at riverbankcomputing.co.uk> wrote:
>
> > On Saturday 06 October 2007, Arve Knudsen wrote:
> > > On 10/6/07, Phil Thompson <phil at riverbankcomputing.co.uk> wrote:
> > > > On Saturday 06 October 2007, Arve Knudsen wrote:
> > > > > On 10/6/07, Phil Thompson <phil at riverbankcomputing.co.uk> wrote:
> > > > > > On Friday 05 October 2007, Arve Knudsen wrote:
> > > > > > > Hi
> > > > > > > I've just written a Designer plugin in Python, which I have to
> > say
> > > >
> > > > is
> > > >
> > > > > > very
> > > > > >
> > > > > > > nice. However I discovered some surprising behaviour in pyuic.
> > My
> > > > > > > widget contains Qt properties (defined using pyqtProperty),
> > but the
> > > > > > > generated
> > > > > >
> > > > > > code
> > > > > >
> > > > > > > don't use the properties, instead it tries to use the
> > underlying
> > > > > >
> > > > > > methods!?
> > > > > >
> > > > > > > I discovered this for the reason that I use a different naming
> > > > > >
> > > > > > convention
> > > > > >
> > > > > > > than pyuic apparently expected. For instance, I had a property
> > > >
> > > > "value",
> > > >
> > > > > > for
> > > > > >
> > > > > > > which pyuic expected there to be a setter method "setValue". I
> > hope
> > > >
> > > > it
> > > >
> > > > > > > isn't on purpose that pyuic tries to use underlying methods
> > instead
> > > >
> > > > of
> > > >
> > > > > > the
> > > > > >
> > > > > > > properties themselves?
> > > > > > >
> > > > > > > I'm using PyQt 4.3 commercial edition.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Arve
> > > > > >
> > > > > > If everything is working as it should then it depends on what
> > you
> > > > > > have called
> > > > > > the setter. If it begins with "set" then pyuic (and uic) should
> > use
> > > > > > it directly and not use setProperty(). However this has probably
> > not
> > > > > > had
> > > >
> > > > a
> > > >
> > > > > > lot
> > > > > > of testing.
> > > > > >
> > > > > > What have you called your setter?
> > > > >
> > > > > Let's say the property is called "value". I called my setter
> > > > > _set_value, pyuic inferred the setter's name to be setValue.
> > > > >
> > > > > Does uic behave differently to pyuic?
> > > > >
> > > > >
> > > > > I haven't used uic for some time, but this point is kind of moot
> > since
> > > >
> > > > C++
> > > >
> > > > > doesn't have properties while Python does :)
> > > >
> > > > Qt/C++ does have properties.
> > > >
> > > > > The point is that I can't see
> > > > > that there is any reason for pyuic to try and use the setter
> > method,
> > > >
> > > > when
> > > >
> > > > > it can simply use the property (i.e., obj.value = something).
> > > >
> > > > Because it needs to have the same behaviour as uic. If it doesn't
> > then it
> > > > is
> > > > clearly a pyuic bug. If not then it may be a bug in the
> > implementation of
> > > > pyqtProperty.
> > >
> > > I'm not sure I follow you here, but I'll let you comment on my
> > attached
> > > example first.
> > >
> > > Can you send me a .ui file?
> > >
> > >
> > > Better yet, I've attached a modified PyDemo example where the setZoom
> > > method is renamed to _set_zoom (to mimic my naming convention) and a
> > basic
> > > form using the widget. This illustrates the problem. There's no
> > problem
> > > modifying PyDemo's zoom property as it were another attribute, e.g.,
> > > demo.zoom = 1, but the pyuic generated code insists on calling setZoom
> >
> > > which isn't there.
> >
> > It is fixed in tonight's snapshot. The fix is to call setProperty() (as
> > uic
> > does). Setting the attribute directly would only work if the property
> > was
> > defined using pyqtProperty, but pyuic cannot distinguish between those
> > and
> > ordinary Qt properties and so it has to assume the latter.
>
>
> Great, thanks for fixing this. I didn't consider that pyuic has to deal
> with both Qt and PyQt properties.
>
> Arve
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20071008/4d53a138/attachment.html