[Pygui] signals and slots

[Mark Summerfield]

On 2009-11-30, Greg Ewing wrote:
> Mark Summerfield wrote:
> > Signals and slots are used to combine widgets to get particular
> > behaviours, e.g., to only enable an OK button if various fields are
> > filled in, or to repsond to a button click, that kind of thing. Qt's
> > event handling mechanism is used for creating custom widgets.
> 
> Yes, I know it's not quite the same thing, but it's
> an example of the same kind of plug-handler-into-slot
> programming style. Sometimes it's okay, other times it
> seems less concise than it could be. PyGUI's action
> properties actually let you treat it either way --
> you can either plug in a handler or have it send an
> event message.
> 
>  > I know that it is nice creating things from scratch
> 
> Actually, Qt is the one that's inventing things from
> scratch. They the advantage that they're implementing
> everything themselves, so they have total control over
> how it all works.
> 
> PyGUI has to work with whatever the platform provides,
> and sometimes there are severe limitations on the hooks
> available for doing this kind of thing.

If you go that route you may end up doing things the wxWidgets/wxPython
way. For single-platform development that's no problem, but for those
who want to develop cross-platform GUI applications it is a real pain
(in wx) that some of the widgets are platform-specific, so you can't
guarantee uniform functionality. I think in the end they had to develop
generic widgets (which as you know, is the route Qt took). Using the
underlying widgets will give you a fast track to having something that
works---but to avoid frustration later on I hope you'll (1) provide a
mechanism for creating custom widgets (with full control over both
appearance and behaviour), and (2) you'll provide a fully cross-platform
API so that people don't get caught out just because they've changed
platform.

> A full-blown Qt-like signal-slot mechanism would be a
> nice thing to have, but it's not easy to build one on
> top of a system that wasn't designed for it.
> 
> > PyQt represents
> > a lot of prior art that has proved very durable and popular so I think
> > you'd at least find it interesting to try it out
> 
> I have used Qt, but it was a long time ago, and in
> C++ :-(. I'll take a look some time and see what it's
> like these days. Need to finish wrestling with printing
> first, though...

That was probably Qt 3 or earlier---Qt 4 is much more mature,
consistent, and wide-ranging in its functionality---and is LGPL of
course.
 
I'm not really sure why (apart from the fun of it:-) you want to build
another Python GUI --- after all, if you want to ground break you could
help out the PySide guys. They're starting with PyQt (so they get
massive functionality out of the box), but they are not tying themselves
down to the PyQt API...


-- 
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
    C++, Python, Qt, PyQt - training and consultancy
        "Programming in Python 3 (Second Edition)" - ISBN 0321680561