[PyQt] Is the result of SIGNAL() a constant?
phil at riverbankcomputing.co.uk
Wed Jan 9 15:41:42 GMT 2008
On Wednesday 09 January 2008, Giovanni Bajo wrote:
> On 1/9/2008 4:03 PM, Phil Thompson wrote:
> > On Wednesday 09 January 2008, Aaron Digulla wrote:
> >> Quoting Phil Thompson <phil at riverbankcomputing.co.uk>:
> >>> What about...
> >>> foo(const QString &)
> >>> foo(QString *)
> >> Can you give an example with two signals with the same name and such
> >> parameters? I can't imagine to see that for any single class. It
> >> *might* happen with signals from different classes but there, we have
> >> a clean slate, so I don't think it's an issue unless you can prove me
> >> wrong.
> > I don't have a real example, but that's not the point. The point is that
> > they are different as far as Qt is concerned and so both need to be able
> > to be represented in the same class (even though the programmer that
> > designed the class needs to be shot).
> But given that such users can still obtain the same features
> (auto-completion, etc.) through usage of constants:
> class Foo(QObject):
> SIG_FOO_1 = SIGNAL("foo(QString*)")
> SIG_FOO_2 = SIGNAL("foo(const QString &)")
> What is exactly the advantage of supporting this feature out-of-the-box
> in PyQt?
Very little if that's all it was.
I was thinking of introducing a new object that could be bound to a class
instance so that you could drop the first argument to connect(). For
It would be nice if you could somehow drop the args if there was only
one "foo" signal - but that has obvious dangers with future changes to the Qt
Or even just add SIGNAL as a method to QObject and retain the current method
of specifying arguments, ie...
self.connect(baz.SIGNAL("const QString &"), self.bar)
As I said, I haven't thought it through yet.
More information about the PyQt