[PyKDE] SIP questions

[Phil Thompson]

Per Wigren wrote:
> 
> Today I started porting the damn KDE2 bindings myself.... ;-)
> 
> I've got a couple of questions:
> 
> 1:
> In kpixmap.h:
> 
> class KPixmap : QPixmap
> {
> <bla bla bla>
> public:
>         KPixmap() : QPixmap();
> <bla bla bla>
> };
> 
> Sip cannot parse this. I'm VERY novice in C++ but I think this one means that
> it uses QPixmap's constructor instead of creating an own, right?

C++ allows you to mix implementation with specification.  SIP is only
interested in specification - so omit any implementation details you
find.  In this case just do:

	KPixmap();

> 2:
> KURL has a class-in-a-class..... Sip fails on the following:
> 
> class KURL
> {
> <bla bla bla>
> public:
>         class List : public QValueList<KURL>
>         {
>         public:
>                 List();
>                 List(const QStringList&);
>         };
>         KURL();
>         KURL(const QString&);
> <bla bla bla>
> };
> 
> Is this because Sip doesn't support subclasses or is it the <KURL> thingy?

SIP doesn't support sub-classes.  It looks like it might need to.

> It's the "class List : public QValueList<KURL>" line that makes Sip scream
> out loud.. ;-)
> 
> 3:
> In the "old" kpixmap.sip there's some %Membercode and it includes
> sipqtQcolor.h. What is it with kpixmap that make this necessary?

kpixmap needs %MemberCode to handle the unsigned* argument to
patternFill().  That member code needs access to the sipqtQColor.h file
to get access to sipClass_QColor.  Normally SIP includes all the right
headers - but it doesn't look at %MemberCode.  In this case it isn't
strictly necessary to explicitly include the header file because it will
be automatically included anyway because gradientFill() also uses QColor
(and doesn't have any %MemberCode).

> 
> I'm willing to make bindings for all of the KDE2 classes, but I won't touch
> Sip....

Good luck - ask as many questions as you want.

Phil