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
