Roland Schulz schrieb:
I understood this, but I thought incorretly that there are classes more
apropriate to use then directly using QMetaObject. But I was wrong and
you're
right QMetaObject should be implemented if someone wants to write
something
like designer in pyqt. But why not just using d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Freitag, 20. Februar 2004 10:59 schrieb Ulrich Berning:
> Roland Schulz schrieb:
> >On Do, 2004-02-19 at 11:55, Ulrich Berning wrote:
> >>Phil Thompson schrieb:
> >>>On Wednesday 18 February 2004 19:04, Eron Lloyd wrote:
> >>
> >>Nevertheless it mak
Roland Schulz schrieb:
On Do, 2004-02-19 at 11:55, Ulrich Berning wrote:
Phil Thompson schrieb:
On Wednesday 18 February 2004 19:04, Eron Lloyd wrote:
Nevertheless it makes sense to implement QMetaObject and
QMetaProperty, just in case so
On Do, 2004-02-19 at 11:55, Ulrich Berning wrote:
> Phil Thompson schrieb:
> > On Wednesday 18 February 2004 19:04, Eron Lloyd wrote:
> Nevertheless it makes sense to implement QMetaObject and
> QMetaProperty, just in case someone plans to build a kind of dialog
> editor with PyQt (in the future,
Phil Thompson schrieb:
On Wednesday 18 February 2004 19:04, Eron Lloyd wrote:
Would there be any benefit in doing this? From the way I understand it, all
Qt objects already expose their get/set methods, while any objects you
create through subclassing can simply use Python's native
On Wednesday 18 February 2004 19:04, Eron Lloyd wrote:
> Would there be any benefit in doing this? From the way I understand it, all
> Qt objects already expose their get/set methods, while any objects you
> create through subclassing can simply use Python's native properties
> support. For the mos
Eron Lloyd wrote:
Would there be any benefit in doing this? From the way I understand it, all Qt
objects already expose their get/set methods, while any objects you create
through subclassing can simply use Python's native properties support. For
the most part, properties have their biggest valu
Would there be any benefit in doing this? From the way I understand it, all Qt
objects already expose their get/set methods, while any objects you create
through subclassing can simply use Python's native properties support. For
the most part, properties have their biggest value in use with Desi
On Wednesday 18 February 2004 13:16, Stefan Seefeld wrote:
> Phil Thompson wrote:
> > SIP v4 classes are new-style classes.
>
> Wonderful ! Are there plans to map Qt properties to
> python properties ? (sounds like an easy thing to
> do given the technical parallels...)
No, no plans.
Phil
__
Phil Thompson wrote:
SIP v4 classes are new-style classes.
Wonderful ! Are there plans to map Qt properties to
python properties ? (sounds like an easy thing to
do given the technical parallels...)
Regards,
Stefan
___
PyKDE mailing list
On Saturday 14 February 2004 15:54, Stefan Seefeld wrote:
> hi there,
>
> I'v tried to write python classes that derive
> from pyqt classes and 'object' (or any derivative
> thereof), which immediately segfaults the application
> as soon as such an object is constructed. Is there
> any flag to set
Stefan Seefeld wrote:
hi there,
I'v tried to write python classes that derive
from pyqt classes and 'object' (or any derivative
thereof), which immediately segfaults the application
as soon as such an object is constructed. Is there
any flag to set when compiling sip and or pyqt to
enable new-sty
hi there,
I'v tried to write python classes that derive
from pyqt classes and 'object' (or any derivative
thereof), which immediately segfaults the application
as soon as such an object is constructed. Is there
any flag to set when compiling sip and or pyqt to
enable new-style classes ?
Thanks,
13 matches
Mail list logo
