[PyKDE] PyKDE compling woes with current snapshots

[Jim Bublitz]

On 24-Apr-03 Gordon Tyler wrote:
> Jim Bublitz wrote:
>> However, if sip is generating sipParseArgs and using a0 I'd
>> guess you're stuck with that. Are you sure the member code is
>> necessary if that's the case?
 
> I'm not sure. Now that I've stared at it for a bit, it seems
> wrong. The whole class definition in the .sip seems odd.
> KURL::List in the KDE headers is essentially a QValueList<KURL>.
> Isn't there a standard way of  mapping this in sip? Should there
> rather be a mapped type to convert  KURL::List to/from a Python
> list?

The problem with KURL::List is that it's a template *subclass* and
not a template *class*, and you need to be able to instantiate it in
Python (which you can't do with a mapped type). sip however doesn't
need to be told about KURL::List's shady ancestry, but then it
doesn't inherit any methods from QValueList either. The additional
methods are to make it behave in a more 'list-like' fashion:
__contains__ let's you use Python's "in" test, __getitem__ lets you
index it ( [] ) and __len__ lets you use "len()". I thought this
was so cool, I stole it from Phil (QStringList I think), but I
didn't modify the methods correctly to adapt them to KURL::List
("the weed of crime bears bitter fruit") That's what I just fixed.
 
>> There were bugs in this section of code, and I've patched them a
>> little differently than you have.
 
> I just hacked until it compiled ;)

It's always compiled before (might not with recent changes though)
- it just never worked.
 
>> like sip is losing track of one of the identically named
>> methods, but it's hard to say. I'd want to check it out before
>> assuming it's a sip bug. 
 
> I'll leave it in your capable hands 8)

Hans-Peter Jansen's post in this thread suggests a possible fix:

There are two methods in KParts::PartBase

    virtual void setInstance (KInstance *);
    virtual void setInstance (KInstance *, bool);

My guess is if you looked at the C++ code to find out what the
'bool' does, you could replace both with:

    virtual void setInstance (KInstance *, bool = 1);

or "= 0" depending on what it does. I'd bet it'd compile. As a user
I don't think you'd be able to tell the difference (and sip won't
object to the default, because it's not part of the method's
signature). Or else you could simply comment out one method in the
sip file (parts.sip) and the problem would go away temporarily. 

It *looks* like a sip problem, but I'd want to look at what sip is
actually generating (and compare it to sip 3.5) before claiming
that.

If everything else compiles, fixing parts.sip should get you going
(just don't expect the extra KURL::List methods to work).

Jim