On Thursday 17 January 2008, Ewald de Wit wrote:
> On Thursday 17 January 2008 18:27:19 Peter Shinners wrote:
> > > button.clicked.connect(self.onButtonClicked)
> >
> > Is there a clean way to handle signals with the same name that take
> > different arguments? Here's an idea I can think of for Q
On Thursday 17 January 2008 18:27:19 Peter Shinners wrote:
> > button.clicked.connect(self.onButtonClicked)
>
> Is there a clean way to handle signals with the same name that take
> different arguments? Here's an idea I can think of for QComboBox.
>
> combo.activated[int].connect(callback1)
> c
Peter Shinners schrieb:
>> Remember: If everyone in the world would develop software
>> the way you do, you'd be unemployed.
>
> I'm not sure how to interpret this. I hope to keep using Pyqt for a long
> time.
I'm trying to make you understand that your way of developing software
works for *you*
Aaron Digulla:
> I've wasted several hours searching for typos so far, so
> I can't live with the current state and making this area
> even more volatile will only increase the chance that I'll
> give up on PyQt and create a fork.
At minimum I'm talking about the simplification of a single argumen
Peter Shinners schrieb:
> But I don't really have problems with the existing
> connect function. If we could just get rid of the SIGNAL requirement and
> pass a string argument it would get a whole lot nicer.
I've wasted several hours searching for typos so far, so I can't live
with the current s
Ewald de Wit
> Wouldn't it be nicer if the signals where attributes of your object,
> so that you could write
>
> button.clicked.connect(self.onButtonClicked)
Is there a clean way to handle signals with the same name that take
different arguments? Here's an idea I can think of for QComboBox
Quoting Ewald de Wit <[EMAIL PROTECTED]>:
On Wednesday 16 January 2008 09:21:40 Aaron Digulla wrote:
As for making the API simpler, I'd opt for
button.connectClicked(self.buttonWasClicked)
Wouldn't it be nicer if the signals where attributes of your object,
so that you could write
On 2008-01-17, Ewald de Wit wrote:
> On Wednesday 16 January 2008 09:21:40 Aaron Digulla wrote:
> > As for making the API simpler, I'd opt for
> >
> > button.connectClicked(self.buttonWasClicked)
>
> Wouldn't it be nicer if the signals where attributes of your object,
> so that you could write
On Wednesday 16 January 2008 09:21:40 Aaron Digulla wrote:
> As for making the API simpler, I'd opt for
>
> button.connectClicked(self.buttonWasClicked)
Wouldn't it be nicer if the signals where attributes of your object,
so that you could write
button.clicked.connect(self.onButtonCl
Pete Shinners:
> Creating a method or constant for each type of signal does solve
> "d" and "f", but comes at a cost.
>
> 1) Adds new methods or symbols that are not a part of Qt.
> 2) Breaks non-qt widgets that have custom signals.
> 3) Ambiguity for overloaded signals like QComboBox's "activated
Aaron Digulla:
> You're missing my point: I try to reduce the amount of typos.
> If all signals in Qt were predefined constants in PyQt, then
> a typo would result in "attribute not found" exceptions when
> they are defined instead of volatile "doesn't work" bugs when
> they are used for the first
Just jumping in on the thread here,not replying to anyone in particular.
I modified (polite word for "hacked up") an example program written by Troy
Melhase for PyKDE3, and what he had done was kind of interesting, I thought:
sigClicked = SIGNAL ("clicked ()")
class MainWindow (KMainWindow):
Quoting Peter Shinners <[EMAIL PROTECTED]>:
That's why I'm against string literals in an API. If that API doesn't
even offer any checks to string literals, that's even worse.
I'd be against using constants to define the signals. What type of value
is going to match things like "const QString&"
Aaron Digulla:
> No, you still have to wrap the string in a call to QtCore.SIGNAL()
> but that's still a "string" to me: No type checking, no way to know
> if your signal is really connected to anything and whether it will
> fire or not.
>
> That's why I'm against string literals in an API. If that
Peter Shinners schrieb:
> Aaron Digulla:
>> Sorry, I can't follow you here. 1) signal and slot already
>> take string arguments. This discussion is to get rid of them.
>
> I get "TypeError: argument 2 of QObject.connect() has an invalid type"
> when I try to pass a string to connect. Is this a cha
Quoting Peter Shinners <[EMAIL PROTECTED]>:
No, but a few ideas have been thrown around on the list in the past
couple
of days.
Your suggestion is nice and concise - the dropping of SIGNAL() was
briefly
discussed during developed of PyQt4.
Allowing string arguments for the signal/slot nam
> No, but a few ideas have been thrown around on the list in the past
couple
> of days.
>
> Your suggestion is nice and concise - the dropping of SIGNAL() was
briefly
> discussed during developed of PyQt4.
Allowing string arguments for the signal/slot name would be a good
improvement. Hopefully th
On Thursday 10 January 2008, Peter Shinners wrote:
> I'm sure this has come up, but as I write my Pyqt code, I keep noticing
> that the QObject.connect call feels like a wart. Is there already a pyqt
> shortcut for a call like this?
>
> QtCore.QObject.connect(myButton, QtCore.SIGNAL("clicked()"
I'm not sure how accepted that approach is, but I personally really
didn't like having to say QtGui and QtCore all the time, so I "from
... import *"-ed those. This makes a connect a couple words shorter
and a lot less hideous.
On Jan 10, 2008 6:26 PM, Peter Shinners <[EMAIL PROTECTED]> wrote:
>
I'm sure this has come up, but as I write my Pyqt code, I keep noticing
that the QObject.connect call feels like a wart. Is there already a pyqt
shortcut for a call like this?
QtCore.QObject.connect(myButton, QtCore.SIGNAL("clicked()"),
onClicked)
The closer I could be to something like the
20 matches
Mail list logo