Re: [PyKDE] PyKDE and KDE 3.4.0

2005-03-02 Thread Simon Edwards
On Thursday 03 March 2005 07:18, Jim Bublitz wrote: > I just compiled the latest PyKDE snapshot (20050301) against KDE 3.4.0rc1 and > it compiles without a hitch and seems to work fine (didn't test much though). In KDE CVS there have been problems w.r.t. the coming gcc symbol visibility featur

Re: [PyKDE] [RFC] [PATCH] Adding support for templated container types to sip

2005-03-02 Thread Bryan O'Sullivan
On Wed, 2005-03-02 at 22:05 -0800, Jim Bublitz wrote: > > For non-simple value types (the things inside the containers), you must > > tell sip how to handle the value type, or it will produce an error > > message. No surprise there. > > Could you expand on this a little more? Will it automatical

[PyKDE] PyKDE and KDE 3.4.0

2005-03-02 Thread Jim Bublitz
I just compiled the latest PyKDE snapshot (20050301) against KDE 3.4.0rc1 and it compiles without a hitch and seems to work fine (didn't test much though). There's one other patch that I didn't apply to PyKDE - Bryan O'Sullivan's "-L" patch for 64 bit AMD compatibility. I'll try to get that into

Re: [PyKDE] [RFC] [PATCH] Adding support for templated container types to sip

2005-03-02 Thread Jim Bublitz
On Wednesday 02 March 2005 11:39, Bryan O'Sullivan wrote: > I've been working on a patch to sip 4.2 that adds support for templated > container types. > This lets sip automatically generate code to handle mapping between a > templated C++ container type and a Python collection of the appropriate

[PyKDE] pure virtual and operator ()

2005-03-02 Thread Paul F. Kunz
I'm trying to expose an abstract base class. In my .sip file I have virtual double operator()(double) const = 0; >From sip command I get sip -e -g -c . -I /usr/local/share/sip -I /usr/local/share/sip/qtcanvas -I ../../hippodraw/sip \ -t Qt_3_3_0 -t WS_X11 ../../hippodraw/sip/sihippo.sip

Re: [PyKDE] [RFC] [PATCH] Adding support for templated container types to sip

2005-03-02 Thread Bryan O'Sullivan
On Wed, 2005-03-02 at 11:39 -0800, Bryan O'Sullivan wrote: > The patch has the following caveats: One final one: I don't yet make any attempt to identify typedefs. So something like this will currently fail: typedef std::list intlist; %MappedType intlist; This should be easy en

[PyKDE] [RFC] [PATCH] Adding support for templated container types to sip

2005-03-02 Thread Bryan O'Sullivan
Hi - I've been working on a patch to sip 4.2 that adds support for templated container types. This lets sip automatically generate code to handle mapping between a templated C++ container type and a Python collection of the appropriate variety. Some background: right now, if you want to map betw

[PyKDE] importing with eric

2005-03-02 Thread Eduardo Suarez
Hello all, I'm looking for a nice development platform to work with qt and python. My main problem, is that i would like to make use of http://www.itk.org/ and it takes some time in my machine every time i need to import it. I have tried not to close the default python interpreter to rerun an qt

Re: [PyKDE] exiting an application cleanly

2005-03-02 Thread Flávio Codeço Coelho
On Wednesday 02 March 2005 07:37, Eli Yukelzon wrote: Hi, I am not quite sure what you meant by mixing threads (I am new to pyQt), but... I am not using threads explicitly( i.e., through threading/threads modules). However, I start some processes with os.system that may be causing it. I'll ch

Re: Re: Re: [PyKDE] Compiling PyKDE 3.11.3 on Solaris 8 fails

2005-03-02 Thread Holger Joukl
Just a short update: I managed to compile on my solaris machine now, here is the version summary (a full description of the necessary config/tweaks will follow later on): Solaris 8 gcc 2.95.2 PyKDE version 3.11.3 PyQt version is 3.13 (3.13.0) sip version is 4.1.1 (4.1.1) Python version is 2.3.4 Qt

Re: Re: [PyKDE] Compiling PyKDE 3.11.3 on Solaris 8 fails

2005-03-02 Thread Holger Joukl
>Just in case I might need it, is there someway for configure.py to figure out >it's running Solaris (eg an /etc/Solaris-release file or something similar)? >Jim Jim, maybe you could test if the os.uname() function is available (which it is on "recent flavors of Unix", according to python docs :-