On Wednesday 23 January 2008, Aaron Digulla wrote:
Phil Thompson schrieb:
Signals are passed to QObject's [dis]connect() and emit() methods.
Currently, If the signal is invalid then no indication is provided to
that effect. If a simple string is used instead of SIGNAL() then an
invalid
On Wednesday 23 January 2008, Andy Davidoff wrote:
On Jan 21, 2008 10:20 AM, Phil Thompson [EMAIL PROTECTED] wrote:
Question: An alternative approach would be to define a default signal
(in the .sip files) which would identify the overload to be used with the
short form. As most Qt signals
On Thursday 24 January 2008, David Boddie wrote:
On Mon, 21 Jan 2008 15:20:16 +, Phil Thompson wrote:
I plan to make changes in two stages.
Stage 1
[...]
Question: It would be possible to allow (but not require) short-circuit
signals to be predefined using __pyqtSignals__.
Phil Thompson wrote:
On Thursday 24 January 2008, Doug Bell wrote:
Of the 13 overloaded signals, how many have int and const QString
choices?
11 might be squeezed into that category but only with a more complicated
categorisation than an index or a string representation.
BTW, 23% of
Am Donnerstag, 24. Januar 2008 schrieb Doug Bell:
Phil Thompson wrote:
About 4% of signals are overloaded. I think your point would be an
issue if that proportion was significantly higher, ie. if a newbie
would be likely to come across both short and long forms in, say, the
tutorials.
Hans-Peter Jansen wrote:
Am Donnerstag, 24. Januar 2008 schrieb Doug Bell:
Of the 13 overloaded signals, how many have int and const QString
choices? That seems to be the most common overload - giving either an
item's index or its string value. Perhaps choosing either int or
QString as
The program listed below downloads the broadcast schedule of a radio station
for the cureent day and the three following.
For each date , it reads an url, updates the progressBar and prints out in a
QListWidget the date corresponding to the url just downloaded.
When I run this program, the
On Thu Jan 24 10:34:37 GMT 2008, Phil Thompson wrote:
On Thursday 24 January 2008, David Boddie wrote:
I still can't see the attraction of this syntax. I sort of see the point
of things like
button.clicked.emit()
but the stage 2 connect syntax looks inside-out.
Because it's
On Jan 24, 2008, at 5:27 AM, Phil Thompson wrote:
The design guarantees no future compatibility problems. What do you
mean
by could create/hide bugs?
Although I don't use an IDE or code completion, I would still
prefer a
more explicit type string over an implicit one. I'd rather the code
On Thursday 24 January 2008, David Boddie wrote:
On Thu Jan 24 10:34:37 GMT 2008, Phil Thompson wrote:
On Thursday 24 January 2008, David Boddie wrote:
I still can't see the attraction of this syntax. I sort of see the
point of things like
button.clicked.emit()
but the stage
On Thu Jan 24 13:40:47 GMT 2008, Phil Thompson wrote:
On Thursday 24 January 2008, David Boddie wrote:
Not that there's anything wrong with that - it's just a different focus.
Yes, but your suggestion (which I like)...
btn.connect(clicked(), self.on_clicked)
...has the same issue.
On Thursday 24 January 2008, Andy Davidoff wrote:
On Jan 24, 2008, at 5:27 AM, Phil Thompson wrote:
The design guarantees no future compatibility problems. What do you
mean
by could create/hide bugs?
Although I don't use an IDE or code completion, I would still
prefer a
more
Is there a way to handle the uncaught exceptions that happen in PyQt?
Usually Pyqt just prints the exception and traceback when returning from
python handlers. I know Python has a global uncaught exception handler,
but my first guess would be that PyQt is not using that?
13 matches
Mail list logo
