Hi Marc, hi Jim, I finally touched the khtml_part problem. Here is my mod:
--- ../PyKDE-3.3.2.orig/sip/khtml_part.sip 2002-08-21 20:08:45.000000000 +0200 +++ ./sip/khtml_part.sip 2002-10-16 13:02:32.000000000 +0200 @@ -124,8 +124,8 @@ QRect r; int i = 0; - if (sipParseArgs(&sipArgsParsed,sipArgs,"mJ0J0ii",sipThisObj,sipClass_KHTMLPart,&ptr, sipClass_QPainter, p, - sipClass_QRect, r, i)) + if +(sipParseArgs(&sipArgsParsed,sipArgs,"mJ0J0JOi",sipThisObj,sipClass_KHTMLPart,&ptr, +sipClass_QPainter, p, + sipClass_QRect, &r, i)) { bool b; At least, it compiles, but does this make sense also? I moderately sure about the missing &, which fixes the compiler complaint, but what about this sip argument format string? Please comment! Thanks, Hans-Peter On Wednesday 16 October 2002 11:10, Marc Schmitt wrote: > On Mittwoch, 16. Oktober 2002 02:48, Jim Bublitz wrote: > > > Nope. I changed that (and some randomly some other permutation of > > > that occurance within khtml*.sip) but without success. > > > > I'm not sure what you mean here - the 'ii' means it's looking for > > two ints passed in, but only one is passed in PyKDE (the second from > > the original declaration was a bool *, which PyKDE *returns* as a > > value in a tuple). "ii" is only wrong if only one int is expected > > in the arg list; it would be correct for two ints in the arglist, > > which isn't the case here. > > I first assumed replacing the (to me mysterious) string "mJ0J0ii" had > helped and brought me further (which was a mistake, I just looked at the > wrong lines) so I thought, "Hey, if this helpes lets edit some others too" > :) > > About the internals of sip I know not much. I've read a bit about swig, and > used it once but not sip. > > > Ooops! My mistake (in more ways than one). The exact same code is > > in khtml_part.sip (cut and pasted, I'm sure), so you might try > > another iteration of the same fixes but on khtml_part.sip instead. > > It doesn't seem likely that the extra 'i' is the problem though - > > I'm not sure what is. Anybody recognize the meaning of "non-POD > > type"?? > > I found this : > > http://www.boost.org/libs/python/doc/v2/definitions.html > > POD: A technical term from the C++ standard. Short for "Plain Ol'Data": A > POD-struct is an aggregate class that has no non-static data members of > type pointer to member, non-POD-struct, non-POD-union (or array of such > types) or reference, and has no user-defined copy assign- ment operator and > no user-defined destructor. Similarly, a POD-union is an aggregate union > that has no non-static data members of type pointer to member, > non-POD-struct, non-POD-union (or array of such types) or reference, and > has no user-defined copy assignment operator and no user-defined > destructor. A POD class is a class that is either a POD-struct or a > POD-union. An aggregate is an array or a class (clause 9) with no > user-declared constructors (12.1), no private or protected non-static data > members (clause 11), no base classes (clause 10), and no virtual functions > (10.3). > > and especially this one : > > http://lists.trolltech.com/qt-interest/2002-03/thread00004-0.html : > > [Q:] > I'm trying to use QString::sprintf with little luck. > During compilation I get the following warnings: > > g++ -c -pipe -Wall -W -O2 -DQT_NO_DEBUG -I/var/tmp/qt/include > -I/var/tmp/qt/mkspecs/default -o main.o main.cpp > main.cpp: In function `int main (int, char **)': > main.cpp:50: warning: cannot pass objects of non-POD type `class > QString' through `...' > main.cpp:50: warning: cannot pass objects of non-POD type `class > QString' through `...' > > [A:] > > You can't pass QStrings through QString::sprintf(). > > [A2:] > > Yes, you can, but you'll lose some Unicode information: > sprintf("%s", string.latin1()) > or just > sprintf("%s", (const char*)string) > > > This leas me to the following conclusion : Its not KDE3.0.4 that changed, > but GCC3.2 ! Before it has been just a warning, now it's an error ... So, > what do you think ? > > That's exactly the reason why I stopped developing C(++) and started > python. > > c-compiler-developer : "Hey, compiling is just too easy. Lets do some > education on our users and show them how -officially- standarized code must > look like ..." > > > -Marc > > ps: I'm just compliling without the paint method. Let's see. > > _______________________________________________ > PyKDE mailing list [EMAIL PROTECTED] > http://mats.gmd.de/mailman/listinfo/pykde _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde