On 10/10/2016 07:32 AM, Veek M wrote:
> Whaaa...t?? Could someone explain what exactly is his grand design
> besides being awfully circuitous? So he has some other Form thingy.. and
> in that he sets up another mapping from ZeroSpinBox.atzero -->
> ZeroSpinBox.announce ???? where's announce and atzero defined?
In your example code, "atzero" is implicitly defined as a signal in the
connect() call. Under the hood in Qt, signals are all dispatched by
strings when you emit() the signal. PyQt does allow you to define
signals in a more pythonic way using class variables:
class Foo(QWidget):
atzero = SIGNAL( signature )
The signature can be a list of python types, or strings describing the
C++ types. This is where the C++ nature of Qt leaks into PyQt. In C++
since the moc compiler takes C++ code and C++ type names and generates a
meta-class that defines signals in terms of strings (moc does basic
compile-time type checking), in Python we also have to provide
signatures in strings also if we need something more than core python
types (int, bool, etc). This signature helps PyQt (well Qt really)
marshal the types properly when the signal's callback is called.
But yes the example is convoluted and circuitous. I think it's just to
demonstrate how signals and slots work, though. That's what the
comments make clear. This isn't how you'd implement a real widget with
customized behavior.
In general I don't think widgets normally want to catch their own
signals. There are other mechanisms for that. Usually you subclass the
widget and then override the appropriate *Event() method. For example,
to do something special on value changes I believe you'd subclass
QSpinBox and override the changeEvent() method. Inside that you would
get your value, do your logic, and potentially emit a custom signal. And
of course calling the parent changeEvent() to propagate the event
through to the parent class.
--
https://mail.python.org/mailman/listinfo/python-list
