> On Wednesday 30 January 2008, nytmyn wrote:
>> The stage 2 simplified qt signals looks just great :)
>> What about signals declared in Python? I'd really like to have
>> the possibility to declare and use them as the qt ones.
>
> You can do that now using __pyqtSignals__.
>
I know I can use
On Wednesday 30 January 2008, nytmyn wrote:
> The stage 2 simplified qt signals looks just great :)
> What about signals declared in Python? I'd really like to have
> the possibility to declare and use them as the qt ones.
You can do that now using __pyqtSignals__.
> All QObjects derrived classes
The stage 2 simplified qt signals looks just great :)
What about signals declared in Python? I'd really like to have
the possibility to declare and use them as the qt ones.
All QObjects derrived classes are passed as pointers and
the values based classes are (really) often passed as const referen
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
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 s
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()
> > >
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 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.
>
> Bec
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
>
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
> > tutori
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.
>
>
On Thursday 24 January 2008, Doug Bell wrote:
> 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.
> >
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.
>
> Of the overloaded signals, none of the overloads a
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 __pyqtSign
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 mos
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
> >
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__. [dis]connect() and emit()
> could then check the name (b
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 aren't overloaded this would mean that the typ
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 Qt signal will
> cause a Python exception to be
On Monday 21 January 2008 16:20:16 Phil Thompson 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 aren't overloaded this would mean that
> the type string
This reflects my current thinking on introducing new, more convenient ways of
using signals in PyQt. The aims are twofold: to make the use of signals less
error prone and less verbose.
Any changes must preserve backwards compatibility and must provide a general
solution (not just for Qt but als
21 matches
Mail list logo
