[PyQt] pyuic expects certain property methods in Designer plugins

[Arve Knudsen]

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/20071007/6862b73b/attachment.html