[PyKDE] Revisiting an old khtml crash

[Brian Thomason]

Jim Bublitz wrote:

>On Thursday 15 July 2004 09:08, Brian Thomason wrote:
>  
>
>>Worked like a charm Jim, and as you said, it doesn't appear we're
>>missing anything we need from commenting that out.
>>    
>>
>
>Good.
>
>  
>
>>We're deploying this on two distro's - one based on a really old
>>snapshot of Debian Sarge running KDE 3.0.1 and G++ 2.95, and another,
>>based on SID now running KDE 3.2.3 and G++ 3.2.  For the KDE 3.2.3 dist,
>>I packaged pykde 3.11.1 and it worked without even a hiccup.
>>    
>>
>
>  
>
>>With the KDE 3.0.1 dist, I had a few issues:
>>    
>>
>
>  
>
>>1.) KDE < 3.0.2 doesn't appear to have the KURL method, so I changed the
>>configure script to "fool" it into believing I was running KDE 3.0.0.
>>This works on pykde3.11rc1 but not on pykde3.11.1.  They both compile,
>>but I get an unresolved symbol when attempting an import with pykde3.11.1.
>>2.) I had to change the references to LONG_LONG to PY_LONG_LONG (no big
>>deal, saw your email on that),
>>3.) I had to manually include qvariant.h in
>>kdecore/sipkdecorepart0.cpp.  I saw some talk about this on the mailing
>>list but no real answer.  I assume this is a fairly clean "fix"?
>>    
>>
>
>The oldest version I test against is KDE 3.0.3 - I've run out of room to keep 
>all of the older versions available (but I should have all of the KDE 
>source). (1) looks like a versioning error of some sort, which should be easy 
>to track down and fix; KURL should exist for KDE > 2.0 
>
No biggie for us right now - We don't even use it.

>(2) I'd have to go 
>back and look at again - I thought that was Python version related, but I 
>think the code for that still moves around somewhat depending on KDE version, 
>and I might have missed a fix in the older code; not sure.
>
Again, no big deal at all here.

> (3) I don't have 
>an answer for as far as the cause - usually that kind of thing seems to occur 
>because of the way #includes are placed (cpp vs h) or ordered in KDE. I can 
>probably fix that by throwing in a #include some place for qvariant.h. It 
>might be hard to find the right place for compilation without concatenation, 
>but for concatenating (which you're doing since you have the single big cpp 
>file) it shouldn't make a difference where it goes.
>
>  
>
I just slapped it at the top and all seems to work well here with both 
versions of KDE.

We ran into another event related problem that has stopped us in our 
tracks though :-(.  When switching to a khtml view, then switching back 
to any already displayed view that contains a custom event, our 
application (Lsongs) dies.  This is with the text commented out in 
event.sip.  I even went so far as to comment out that same event related 
code in every file that contained it, to no avail.  The behavior 
displayed was the same each and every time.

If you need it, I'll send you the source code of lsongs right over, but 
it is alot to wade through and I didn't want to spam you with it.  I can 
also send you a traceback. (didn't want to spam you with it either)  I 
can write a simple app that displays the problem too if you like, and 
don't want to wade through the lsongs code.

Sorry to keep bugging you.  We just need this capability to deploy 
shoutcast support in lsongs as well as our future music warehouse..

>>Great work you've done here.  I'm shocked more people don't use this.
>>    
>>
>
>I've actually been writing an app with PyQt/PyKDE the last few weeks (and the 
>next few weeks too) and the GUI parts have been a breeze. I'm always amazed 
>at how fast this stuff runs, at least on the GUI level, and it's much easier 
>than trying to do it in C++.
>  
>
Out of curiosity, what type of app are you writing?

>Jim
>  
>

Until next time,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20040716/4e02c588/attachment.html