Re: [PyKDE] PyKDE-3.5-1
On 06-Apr-03 Gordon Tyler wrote: On April 5, 2003 03:40 am, Jim Bublitz wrote: This version requires sip 3.5 and PyQt 3.5. snip This version builds against Python from 1.5.2 through 2.2.2 (haven't tested the 2.3 beta), KDE 2.1.1 through 3.1.1, and Qt 2.3.0 through 3.1.1. I'm trying to compile it against sip-x11-gpl-snapshot-20030322 and PyQt-x11-gpl-snapshot-20030321 on a Debian testing machine with Python 2.2.2, official KDE3.1.1 packages and Qt packages version 3.1.2-0woody1. I manually applied the patches to PyQt required to compile it on Debian (the style stuff). PyQt works fine. Should be no problem (other than below) in compiling against that snapshot. static QPtrListKMainWindow* memberList; But the mapped type in the sip file, MainWindowList, is using QList. I'm changing various references to qlist.h to use qptrlist.h and retrying the compile. I'll let you know which ones I had to change to make it compile. My Qt sources (SuSE and I assume RH, since it compiled here) have the following: in qlist.h (has one): #include qptrlist.h in qptrlist.h: - QPtrList declarations #define QList QPtrList As can be seen from the above, there is no difference except name between QList and QPtrList. Regardless, that should be changed in the PyKDE sources for KDE = 3.0.0. Actually, I thought I had caught all of those. I should have seen those flagged when generating new code. In each of these, you'll need to change QList - QPtrList and qlist.h - qptrlist.h where they occur (that means inside the %MappedType blocks too): khtml_part.sip khtmlview.sip kmainwindow.sip kprocctrl.sip kurifilter.sip kuserprofile.sip kmainwindow.sip would be the first you'd encounter when building. The rest of the occurances appear to be properly versioned out, or the sip files aren't included in the build for KDE 3 versions For example, any QList/qlist.h preceded by: %If ( - KDE_3_0_0 ) won't be seen if you're building with KDE = 3.0.0 (it's effectively the same as '#if KDE_VERSION 300' in C++). Also, if you don't see KDE_3_1_1 at the top of the sip file in the comments, that sip file won't be seen when you build for KDE 3.1.1. I'll try to fixup the build.py bug noted in an earlier post and this one and put out a new release somewhere around the middle of the week (taxes next couple of days). Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] PyKDE-3.5-1
PyKDE-3.5-1 (.tar.gz) is available at: http://www.riverbankcomputing.co.uk/pykde The download link is on the download page. This version requires sip 3.5 and PyQt 3.5. It's a little more than a development snapshot and a little less than what I wanted in a final release. The major deficiencies are a little untested code (for long long handling) and some missing features (demos, docs, more testing, etc.). There is a set of documentation (html) in the tarball, along with a couple new demo programs in the examples*/ directories. The various KSharedPtr based classes (KService, KMimeType, etc) should now work. This version builds against Python from 1.5.2 through 2.2.2 (haven't tested the 2.3 beta), KDE 2.1.1 through 3.1.1, and Qt 2.3.0 through 3.1.1. It's been tested (successfully too) against various SuSE versions (7.1 - 8.1) and RH 8.0 (gcc 2.95 and 3.2). Keep in mind that for PyQt or PyKDE programs to run on SuSE 8.1, it's necessary to export the environment variable KDE_MALLOC = n. Also remember that using the -c switch when running build.py dramatically reduces compile times, for KDE = 3.0.0: python build.py -lqt-mt -c for KDE 3.0.0 python build.py -lqt -c You still need to be root to run make and make install. This version will *not* build with the latest sip snapshot - the fix for that is fairly simple and was posted a few days ago. I'll be taking a few days off to do my business taxes and some other stuff, and then be back at this so that (hpopefully) everything is complete for the Python 2.3 and sip 3.6 releases coming up. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] PyKDE Change in Plans
On 02-Apr-03 Gerard Vermeulen wrote: Hmm..., I was wondering if it is possible to introduce a feature %feature SIP_FOOLS_DAY where build.py (or my distutils scripts) have to figure out if sip predates 2003-04-01 or not. Sure - Take the output of sip -V and test it to determine if you need the old style or new style naming, then pass a -D define to your code when compiling or set a feature conditional (= 3.5 or snapshot-20030401 for old style). There is a #define Phil referenced (SIP_MAJOR_NR) that you can test in C++ code (it's in the 3/15 snapshot), but I think you'll only be able to distinguish 3 from 4, and the incompatibility will be in later versions of 3 already. It's in siplib/sip.h. I'm resistant to doing it for PyKDE because it adds some other complications and it appears at the moment that PyKDE for 3.6 (when 3.6 is released) won't be backwards compatible with PyKDE for 3.5. It's easy to add the #ifdefs if you need them (all the changes are in C++ code in %VirtualCode blocks). PyQt shouldn't have a problem as long as you match the PyQt and sip versions. I like the feature name though :) Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] PyKDE Change in Plans
On 01-Apr-03 Kaleb Pederson wrote:
On Tuesday 01 April 2003 13:23, Jim Bublitz wrote:
Following up on Phil's Incompatible SIP Change message, I've
decided to make a slight change in the PyKDE release schedule.
Within the next couple of days, I'll release a snapshot of the
next PyKDE release. This snapshot will be based on sip 3.5. If
you're using sip 3.5 it will build as delivered.
To use it with the incompatible sip snapshot you'll need to do
the following before building:
1. grep the sip files for sipName:
grep sipName .../sip/*.sip
three dots?
As in something else probably goes there depending on where you
put PyKDE and what the current working directory is and what the
top level PyKDE directory is.
There are only 7 occurances
2. Replace all occurances of sipName_module_something with
sipName_something. For example
sipBadVirtualResultType(sipName_kdeui_KDateValidator,
sipName_kdeui_validate);
becomes:
sipBadVirtualResultType(sipName_KDateValidator,
sipName_validate);
Hmm if you have the appropriate commands installed:
grep -l sipName ../sip/*.sip | xargs -n 1 -i sed -r -i
s/(sipName_)([a-zA-Z]+_)/\1/g {}
Which will do it in one commandline (but with only seven
occurences it might be overkill - however, I've used that to
replace defines, code,etc. many times).
The basic command is:
sed -r -i s/(sipName_)([a-zA-Z]+_)/\1/g filename
which will take:
[EMAIL PROTECTED] kibab $ cat mytestfile
sipName_kdeui_KatePart sipName_kdeui_Mytest
and turn it into:
sipName_KatePart sipName_Mytest
This, of course, assumes that no underscore will be present in
module names.
Correct.
Finally, if I'm wrong and this kills your system, well, oops ;)
I always keep the original tarball as a backup because I don't
these very well.
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] SIP questions
On 02-Apr-03 Claus, Richard wrote:
I have used SIP to provide Python access to a set of C++ classes
I wrote. These classes don't involve either PyQt or Qt.
A few points:
1) I have a placement operator new(size_t sz, void* p, bool swap)
in one of the classes. It is used internally to the C++ code and
is not exposed to Python. When the SIP-generated code is
compiled by VS.NET, it complains about the lack of existance of th
e standard new operator in the code generated for the class
constructors, although it has no problem finding it for classes
not having additional operator news defined. I would have
thought that it should be able to figure out which new to use
from the sig nature. I saw two solutions: 1) Provide a new
operator in my class that has the behaviour of the standard one,
or 2) use the scoping operator (i.e. ::new MyClass) in
%MemberCode. I had to handle the delete operator similarly.
What's the right thing to do? Should SIP be using the scoping
operator in the generated code?
I'm not at all sure on this one, but it sounds to me like either of
your solutions would be worth trying. I'm not familiar with VC, but
I seem to recall that some versions of C++ used to have a standard
new operator that globally overloaded the real new operator - if
new is defined in an h file, you could try including that h file.
2) Some of my C++ classes have pure virtual functions. The SIP
generated code looks like:
int sipMyDatagramIterator::process(MyDatagram * a0)
{
if
(sipIsPyMethod(sipPyMethods[0],sipPyThis,sipName_PKG_MyDatagramIt
erator,sipName_PKG_process))
return
sipMyDatagramIterator::sipVH_process(sipPyMethods[0],sipPyThis,a0
);
}
about which VS.NET rightfully complains:
c:\pkg\sippkgmydatagramiterator.cpp(61) : warning C4715:
'sipMyDatagramIterator::process' : not all control paths return a
value
What sip requires for pure virtuals/abstract classes is that:
a. methods be declared in the sip file as pure virtual
virtual void foo (int) = 0;
b. *all* pure virtuals for the class be declared in the sip file
(even if they're private).
I haven't seen a problem, but PyKDE only has a handful of abstract
classes.
I tried copying this and adding an else clause in %MemberCode,
but it didn't work. I don't remember why.
It probably didn't work because to add %MemberCode to a virtual
method you also need to add a %VirtualCode block - there should be
some examples in PyQt; if not, check the C++ code that sip
generates for a virtual method that works, for example for a
virtual method 'foo' there will be a sipSomeClass::foo method and a
sipSomeClass::sipVH_foo method - the latter is the %VirtualCode
block that sip generated (the VH method will only appear in the base
class that defines the virtual method, I believe).
3) I'm concerned about speed. I'd like certain class methods to
provide access to Numeric or NumArray style arrays, but haven't
figured out how to do that yet. In the mean time, I am trying to
avoid a copy by returning PyBuffer_* in %MemberCode instead of
PyString_*. However, this leads to wanting to pass PyBuffers
into the C++ code and I haven't managed to figure out how to tell
sipParseArgs to accept them. Any suggestions?
Here's a fragment from a method that takes a Python list in place
of the C++ char** argument. The 'T' format specifier in
sipParseArgs (along with the PyList_Type and slist arguments)
handles the Python object. The first int argument isn't passed in
from Python, but is computed in the C++ code - a1 is the second
int arg. The '|' means the int arg is optional, 'm' is for the
the 'this' or 'self' pointer.
void insertStrList (const char**, int = -1, int = -1);
%MemberCode
//returns
//takes list (a Python list of strings) index (int)
KEditListBox *ptr;
PyObject *slist;
int a1 = -1;
int n;
if (sipParseArgs(sipArgsParsed, sipArgs, mT|i,
sipThisObj,sipClass_KEditListBox, ptr,
PyList_Type, slist, a1))
{
if ((n = PyList_Size (slist)) == 0)
return NULL;
Finally, I've fallen into trouble with Python's garbage
collection in that when I use my code in a multithreaded
environment, Python sometimes exits with a complaint about
finding an object on its GC list that has already been collected
(currently not so easy to reproduce, so I don't have an exact
copy of the error message). Given that SIP handles reference
counting, can anyone give me some suggestions for going after
this? The placement new on an existing Python string trick is
little more than casting to give the string a personality.
Maybe this is confusing SIP somehow?
I have no idea on this one.
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] PyKDE trivia
I just finished one cycle of test compiling the next KDE release (I have more testing/bug fixing to go yet), and thought the following results might be interesting. For these compiles, the sip files are all on Machine 3 (1, 2, and 4 access the same file set via NFS over a 100BT LAN), all C++ files are local to each machine. Machines 1, 2, and 3 have identical HDs. Machine 1: 850MHz PIII, 256MB, X not running Machine 2: 800MHz PIII, 272MB, X not running Machine 3: 850MHz PIII, 512MB, X running Machine 4: Athlon 1900, 1GB DDR, X running MachineKDE VersionDistribution build.py make min:sec hr:min:sec ------ -- using tmake, -c switch 3 2.1.1SuSE 7.12:56 12:40 2 2.2.0SuSE 7.33:27 14:47 2 2.2.1SuSE 7.33:42 14:36 2 2.2.2SuSE 7.33:23 15:19 using qmake, -c switch 2 3.0.0SuSE 7.3 13:40 12:42 4 3.0.0SuSE 8.07:15 6:17 2 3.0.1SuSE 7.3 13:42 12:44 1 3.0.3 RH 8.0 7:04 40:56 1 3.0.3SuSE 8.1 12:58 42:36 1 3.1.0SuSE 8.1 13:10 45:51 1 3.1.1SuSE 8.1 13:15 46:21 using tmake, no -c switch 3 2.1.1SuSE 7.13:011:00:50 using qmake, no -c switch 4 3.0.0SuSE 8.08:47 48:10 2 3.0.1SuSE 7.3 17:491:29:37 1 3.1.1SuSE 8.1 16:502:10:06 Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] SIP questions 2
On 27-Mar-03 dwelch wrote: Thanks again to Phil and Jim for all their help. I have 1 additional question at this stage. I am trying to wrap a C++ class that has a member function that takes a fd_set as a parameter. Something like: int DoSpecialSelectLikeOperation( fd_set f ); On my RH8 Linux box, the fd_set is a struct that contains a bitfield. Any suggestions on how to handle this? I got into this once, but quite a while so I'm not sure. I *think* sip handles bit field variables, so first I'd try: int a; int b; for the corresponding bit-field variables. The actual variable declarations from the h file might work too. sip will take the above (sip doesn't look at h files, so it doesn't know any better). It might cause compile or execution errors - you'd want to test it. If it does work, you might have to be careful to not overflow the variables from Python. The other way is to write a %MappedType for fd_set, which would allow you to view it as a tuple in Python and struct in C++. You could also write %MemberCode, but you then have the problem of getting sip to recognize the fd_set type (%MappedType does that for you). In either case you'd be handling the bit-field variables at the C++ level, so it wouldn't be a problem. That would also let you handle overflows from the Python side. (I used to handle all C++ structs as tuples via %MappedTypes, but I write them as classes now). In that case, you wouldn't instantiate fd_set directly in Python - you'd pass in an appropriately structured tuple (or get a tuple back). Writing a mapped type is basically writing one code fragment that converts from C++ - Python and another going the other way. Both use Python/C API functions (and sip generated methods for class conversions) to do the actual conversions. There also is a %VariableCode directive in sip, but there aren't any useful examples in either PyQt and PyKDE (one trivial PyKDE example that's no longer used), and I don't recall if it would help here or not. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] SIP questions
On 25-Mar-03 Phil Thompson wrote: On Tuesday 25 March 2003 7:20 pm, WELCH,DONALD J (HP-Vancouver,ex1) wrote: Greetings- I am attempting to wrap a shared library on Linux using SIP. This shared library's API defines several C++ classes that interelate (in both IS-A and HAS-A relationships). Currently, all the classes are declared in a single .h file. Questions: 1. What is the difference between %Import and %Include? %Import is used when you are wrapping a library that sub-classes from another library that has also been wrapped. So PyKDE effectively %Imports PyQt. %Include is similar to the C pre-processor's #include. Ignoring the fact that Phil wrote sip and I'm just a user, I think %Import is closer to a C++ #include - %Import is like all of the #includes you add *except* the one that has the same name as your cpp file. It provides all of the external refs. %Include is more like the list of source files in the Makefile - the %Includes are the files that comprise the module and the ones code will be generated for. Whether you put each class into a separate .sip file is a readability issue and is up to you. sip still generates one cpp/h file pair per class, but how you distribute classes over sip files makes no difference to anything. Every class needs a %HeaderCode block though, no matter how you arrange things. SIP is run against the qtmod.sip file (not against each individual .sip file) and it brings in all the necessary stuff through %Includes. In that sense sip is more like a linker than a compiler, in that it reads in all of the sip files for a module before resolving symbols. Ignoring scope, any symbol in any sip file is visible to all other sip files, and in fact sip won't tolerate multiple declarations (eg duplicate typedefs). 6. Is it possible to add methods to classes in the .sip file that don't exist in (or exist differently) the wrapped .cpp code? For example, could I add a method that returns a Python list instead of having the Python client code call getFirst()/getNext() to enumerate a list of items? Yes - you can lie to SIP as much as you want. Depending on the nature of the class, alternatives would be to replace the class entirely with a Python list (using %MappedType), or implement appropriate Python operators (see qstringlist.sip). There are a lot of examples in PyKDE - grep the sip files for %MemberCode, %MappedType, %C++Code, or %PrePythonCode. qstringlist.sip is a neat example of handling a template based class (by ignoring the base class) and adding Python __methods__ (same as KURL::List, for which I stole the code from QStringList). KCmdLineArgs has an example of replacing an array of C++ structs with a Python dict. 7. Are there any tools to automate h2sip (at least the basic stuff that can be automated)? Over to you Jim. I have an automated tool that does PyKDE automatically almost perfectly (about a half dozen known errors in 400+ files) except for handwritten code (it did some of that too, but not very well). It also does versioning, writes the docs (minimally at the moment, but I've been thinking of hacking the KDoc stuff too, similar to what theKompany just announced for PyQt), and constructs the build.py file that generates the make files. I sent it to someone last week and quickly realized it's pretty difficult for anyone else to make sense of at the moment, and is also pretty PyKDE specific. That's given me second thoughts about releasing it, but assuming I still do release it, it won't be for 3-6 months. The core parser/sip file generator is pretty good (a few bugs and a lousy C preprocessor parser) but the input file specification is pretty horrible and the build files generated won't work except for PyKDE (but are hackable). I will, however, send you a copy if you want to give it a try. Just don't expect much. It's Python, so it only takes a few minutes to decide if it's worth your effort or not. Let me know. However, be aware that you sometimes have to supply SIP with more information (eg. /Transfer/ flags) which cannot be done automatically. I do those automatically :) - also the SIP_RXOBJ_CON and SIP_SLOT_CON stuff except for the args if needed - I generate them all commented out and then add the args to SIP_SLOT_[CON,DIS] manually. Depends on the consistency of the C++ code though - I just assign every QWidget *parent in a ctor /TransferThis/ and every other case a /Transfer/, and then go back a remove a few manually. Those are almost the only necessary info that's not in the h files (and stuff that needs %MemberCode or %MappedType, which I flag automatically). Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] More SIP questions
On 25-Mar-03 WELCH,DONALD J (HP-Vancouver,ex1) wrote:
Thanks again for the quick response to my earlier queries. I have
an additional point of contention:
Each of these 5 variables and methods in the class are causing me
grief.
I'm guessing at some of these, but on the off chance Phil doesn't
respond, here's what I'd try:
// channel.h
class Channel
{
public:
static const int MAX_LEN = 4096;
int MAX_LEN;
I don't think sip will handle the 'static'. The initialization
should take place in the C++ code (lib), so you shouldn't need to
specify it (and I don't believe sip will let you).
static const char DEF_NAME[] = UNKNOWN;
char *DEF_NAME;
Same - I don't believe sip handles [] (directly).
Channel operator=( const Channel chan );
sip doesn't presently handle operators - might be able to do it in
Python somehow (and embed the code in the sip file); not sure.
virtual ~Channel();
Delete it (if it's public). If it's private, leave it in but drop
the 'virtual'. If it's protected (guessing) make it private (and
still drop the 'virtual').
static void delay( struct timeval value);
'struct timeval' needs a declaration somewhere in the module. I
believe sip handles 'struct' now, but I still convert everything to
classes:
class timeval
{
%HeaderCode
#include ??
%End
public: // a C++ struct is a class whose default access is
// public
...
};
static void delay (timeval);
Note that for methods, 'static' is critical (it indicates that no
'this' pointer is passed in the method call). 'timeval' can be
nested within Channel if that's where the struct is in the h file -
in that case, drop the %HeaderCode block (only use it if the class
declaration occurs outside a class scope - in a namespace or
global). If it's declared inside a different class (or in any named
namespace, including the current namespace), it will have to be
scoped: OtherClass::timeval or SomeNameSpace::timeval.
Same thing exactly for:
typedef struct {...} timeval;
That's still a class declaration - it just looks funny.
Lastly, the 'const' in the first two lines might cause some
compiler problems if omitted - not sure, but I'd try it without
first.
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] KDE3.1.1
KDE3.1.1 has been officially released (I'm downloading it now). KDE3.1.1 will be included in the next PyKDE release (as well as 3.0.4, 3.0.5, and 3.1.0). I don't have a firm date for the release, but it shouldn't be too far off. Adding KDE3.1.1 won't delay the release by more than a day or two (I hope, after reviewing the change log). Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Problems with PyKDE 3.3.2 on KDE 3.1.1
On 19-Mar-03 Hans-Peter Jansen wrote: I've tried to switch off the kio module, but then kfile cannot be built... Because kfile depends on kio. BTW: The KDE 3.1.1 is what I have found on SuSEs 8.2 beta 3, their latest release for us beta testers. As far as I know, there is no official KDE 3.1.1 or even a beta or release candidate. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Problems with PyKDE 3.3.2 on KDE 3.1.1
On 19-Mar-03 Hans-Peter Jansen wrote: On Wednesday 19 March 2003 16:03, Jim Bublitz wrote: On 19-Mar-03 Hans-Peter Jansen wrote: I've had some conversation with Dirk Mueller today about this problem. He holds me, that instancing KService::KService(const KService) will crash anyway, therefore it was made private in KDE 3.1.1 (which will appear soonish). He told me that we need to use KService::Ptr, since KService can only share explicitly, thus it cannot be deep copied. (From memory) That should be what the new code for QPtrListKService::Ptr (which is what SvcList or KService::List is) does I think. If not, I'll fix it. Maybe that was part of the problem with the older code ?? Thanks for the input though - it'll be helpful to know when I'm testing/debugging this. svctypes.sip is handwritten code and SvcList is a mapped type meaning neither is really part of KDE, but are created to handle template classes within PyKDE. I'm not sure why the copy ctor is being invoked there, so I'm not sure how to fix it. Also, I'm not sure if that section of code even works, and it's been recoded already for the new version. Would you mind throwing that code on me? I'd rather not, as I don't know if it works, and I don't have it versioned past KDE 3.0 yet. There were problems with the code in this area in past releases, and it's very easy to write code that compiles but doesn't function here - it's tricky (for me anyway) getting the dereferencing correct. At the moment it's probably better if you just comment out that stuff - should only be a few methods. There's a lot of stuff in PyKDE that nobody uses (although there was a bug report on the list about the above) so for an interim release like you're doing, I'd just comment stuff out 'til it works. You probably won't lose too much that way. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] Hello and PyKDE for KDE 3.1
On 18-Mar-03 Roberto H. Alsina wrote: First: hello, and congrats on the amazing software :-) Second, Since I needed to use KHTML on a app I am writing, and also wanted it to work on KDE 3.1, I made a quick hack of PyKDE-3.3.2 to make it work under KDE 3.1. This is just intended as a stopgap thing until the real thing comes out, and to let any KDE 3.0 PyKDE apps work on KDE 3.1 (since the API is exactly the same). If anyone wants it, it still seems to be stuck in ftp://upload.kde.org The next PyKDE release (covering 3.1) is at least a week or two off, so for anyone wanting something sooner this would be a good idea. Thanks! Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] PyQt QScintilla Status
On 16-Mar-03 Phil Thompson wrote: Tonight's snapshots of SIP, PyQt and QScintilla should be treated as release candidates for SIP 3.6, PyQt 3.6 and QScintilla 1.0. Hould there be a PyQt snapshot? I don't see one. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Any tools to generate sip files?
On 14-Mar-03 Frederick Polgardy Jr wrote: Well, whereas SIP looks at SIP files (a stone's throw from the C++ header file) and generates C++ bindings, I could imagine it wouldn't be *extremely* painful to write a utility like SIP to generate Boost code from the headers, or a slightly modified version thereof, instead. Not saying I'm going to write it myself :), but the point was only that the limitation doesn't lie with Boost itself. Not having looked at Boost lately I'm not sure how difficult it would be, but it's probably doable. I guess my point was that sip already does this and Boost doesn't. The bigger issue re: Qt/KDE is that I have no idea how you'd handle the signal/slot mechanism without having preknowledge about it, like SIP does. Again I'm not familiar enough with Boost to be certain, but it seems that Boost sits on top of the C++ code while sip calls into the C++ code - so, for example, Boost can handle templates more easily than sip can. Signal/slot handling might be easier too since at the C++ level Qt already knows how to do it - it might be just another method call to Boost. It seems to me the biggest difference though is that sip by design handles a comprehensive set of bindings over a number of versions very well, while Boost is designed more to add a Python feature to your C++ code. sip excels at PyQt and PyKDE, but for a lot of applications sip is overkill and Boost is probably more suitable. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] Any tools to generate sip files?
On 13-Mar-03 Hubbard, Dwight wrote: I've been looking at trying to generate python bindings for the libmyth library which is part of the mythtv pvr project ( http://www.mythtv.org) I was wondering if there where any tools to automate the generation of the .sip files from the .h files instead of doing it manually? Almost. I have a tool in development that does automatic h-sip conversion, as well has generating the build scripts and writing some of the docs. I'm using it to generate the next PyKDE version and it's essentially complete enough to do that (ignoring the occasional bug that still pops up now and then). I haven't tried it on anything except PyKDE, so I'm sure there'll be problems with it, particularly in generating the build stuff. I took a quick look at the libmyth sources and only see one problem - one of the h files has a using statement, which is one of the few things I'm not planning on supporting. You'd have to add explicit scoping manually to the variables covered by that statement. I didn't see any place where you'd need to hand write any C++ code for sip, but I only took a quick look. I also didn't check to see what beyond the libmyth h files you'd need sip files for. If libmyth references objects in other libs, you'd need to bind those too or else hide the references somehow (Qt isn't a problem however). The other nice feature of this tool and sip is that they handle versioning - you can build a new set of sip files from the previous version's sip files and the new h files. It looks like this project will be changing fairly rapidly at the moment. If you have a strong urge to be a guinea pig for undocumented and probably somewhat buggy incomplete software, I can send you a tarball (it's all in Python). Basically all you should need to do is create a project file (assuming it works). You'd also need Python 2.2.2, sip 3.5 and PyQt 3.5 (since libmyth is Qt based). This is far from releaseable, but works pretty well. If it works, you'd have sip files in about 20 seconds (all of PyKDE takes about 3 1/2 minutes). There's a strong chance this will be completely useless to you. Otherwise, I can take a look at it myself when I get some time. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] Any tools to generate sip files?
I took a second very quick look at the libmyth sources, and there's good news and bad news: the good news is the using statement is for 'std' (always make me think of sexually transmitted disease), so you won't have to do any explicit scoping. The bad new is that you'll have to hand write mapped type code for all instances of templates from std (but only if they're public or protected - you can ignore all of the private stuff). It's not that hard to do though, and instead of vector you'll get a Python list in the bindings. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] PyKDE Status and Update
PyKDE is (finally) starting to progress. I mentioned earlier that I'm revising the entire process and have most of that done now (at least well enough to start actually generating code). So far, I've built 3 versions (2.1.1 - 2.2.0) and will be starting on 2.2.1 in a few minutes. Starting over from 2.1.1 will give me a much cleaner code base. I've also picked up quite a few unnoticed bugs and a few missing classes/methods/etc by revising the entire process. This is also the last release to support KDE2.x.x, so I'd like it to be fairly clean. In addition, I've started on adding some better demo stuff and testing, and also started on including some templates and examples for writing code with PyKDE. The doc format has been revised and expanded a little (it's now a little more Python oriented than before). There's still a lot to do in all of those areas that probably won't make it into this release. Lastly, I've set up a couple of multi-boot machines so I can test every version (2.1.1-3.1.0) and also test building on RH 8.0 and Mandrake 9.0 in addition to SuSE 7.3/8.0/8.1, with several Qt versions and several Python versions as well. There won't be a lot of apparent changes, but under the hood this should be a much better piece of software. As for a release date -- as always it's a few weeks away. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Any tools to generate sip files?
On 14-Mar-03 Frederick Polgardy Jr wrote:
Well that's essentially what SIP is, although it's more than just
cpp-pyqt/kde, it's cpp-python in general.
I took him to mean he wanted to translate (line for line) C++ into
python, for example:
if (something)
{
x = 1
y = 2
}
to
if something:
x = 1
y = 2
which is not what sip does. Sip provides an interface to C++ libs
on the binary level - it has no idea what's in the cpp code, but
only knows what the call/return interface to the code is (hence sip
only needs to look at the h files, not the cpp files - mostly). The
bindings sip produces are in C++, not Python.
Along the same lines, has anybody checked out Boost.Python by any
chance? It's pretty awesome. The folks at Boost are insane.
http://www.boost.org/libs/python/doc/index.html
I've looked at it (and argued with David Abrams on comp.lang.python
a little) but never tried it. Boost has some advantages over sip,
especially if you only want to bind a few functions, have a lot of
templates, or like writing C++. The drawbacks (in the context of
of a large project like PyKDE anyway) is that it requires a lot of
handwritten code, more knowledge of what the code actually does,
looks difficult to automate, and would be difficult to maintain over
a number of versions (right now PyQt supports everything from Qt1.42
onward, and PyKDE supports KDE 2.1.1 onward, each with a single
file set). Can't say as far as performance, but it seems like Boost
should be pretty fast and perhaps a little smaller in binary size.
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Problem building PyQt, QScintilla, and eric
On 12-Mar-03 Phil Thompson wrote: On Wednesday 12 March 2003 5:57 pm, Greg Fortune wrote: You'll want to build and install qscintilla before building sip. That won't make any difference. It's more likely that a later version of eric is required (ie. a snapshot). General upgrade order: 1) build/install qscintilla 2) build/install sip 3) build/install PyQt 4) go to bed Or use the -c flag, then you only need to get a coffee. I didn't know -c stood for coffee -- I always thought it was for Cardenes :) Jim 5) wake up in the morning. Congrats. PyQt is done ;o) 6) build/install eric ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Problem building PyQt, QScintilla, and eric
On 12-Mar-03 Gerard Vermeulen wrote: On Wed, Mar 12, 2003 at 10:27:51AM -0800, Greg Fortune wrote: Or use the -c flag, then you only need to get a coffee. he he, I'm on a PIII 550 so compiling anything takes a little while :) What does it do? If there is no disadvantage to using -c, could you include that flag by default? It concatenates all sip generated C++ files into a single file. So in the end all header files get parsed once, instead of many times. Some compilers (gcc-2.96) are memory hungry and will start swapping if you use the -c switch (this is also more likely to happen if you have compile Qt with -O3 or more). If the compiler starts swapping to disk you can stay in bed the next day :-) The qt module needs about 100MB of RAM with the -c switch, so on a low memory machine (around 128MB or less) it would be best to not use -c, or at least use it without running X. Otherwise, swapping depends on what you have loaded. On the plus side, it cuts compile times for PyQt and PyKDE by about 80% (on the same machine). On a 600MHz Celeron/64MB RAM/no -c I've had PyKDE take as long as 3-1/2 hours to compile. On an Athlon1900/1GB DDR/-c it takes under 6 minutes. I would think your 550MHz would do PyQt under 15 minutes if you have enough RAM and use -c. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] Printing (General)
On 11-Mar-03 Ken Godee wrote: Nope, QPrinter allows you to set many functions of your device, including resolution, but won't do any layout stuff. Yes you can layout using Designer, then pyuic, then create an instance of that object in your app and grabwidget with QPainter but the problem is it's only at screen resolution ie. 81dpi. If you then set your QPrint device to 600dpi your image will print out aprx. 1/8 scale. If you try to scale up to 600dpi, that won't work either, it will be bigger(full scale), but image will still be at 81dpi. Either way destroys even normal size fonts, QPainter grabwidget converts widget to a pixmap and hands off to QPrinter which paints to your device (or something like that). I would like to print directly to the printer and not to a PDF. I don't really care if it's easy or not, I just want it handle images/fonts/lines correctly and print out at a decent resolution. Here's some of the following I've looked at. Kuger (Qt based,shows promise, no images though) ReKall (Qt/python based, shows promise) DataVision (Java Based shows promise) JFreeReport ReportLab JReport GRG ReportManager Latex and many more. When I started down this road I didn't think I'd have to reinvent the wheel. I still can't believe I'm just not missing something? So far if possible the best combo I can see is to try to extend python with Java (pyJava?) a couple of the programs out there come with complete Java Librarys for report generating/design with complete font scaling and image handling, headers, grouping, etc. But I really wanted to stay in the Qt camp. As far as report generation/layout - I agree there isn't a good general purpose solution that I'm aware of (good project possibility for someone who's interested). As far a QPrinter - I went back and looked at my code. I haven't worked on this for about a year and the project wasn't completed. Apparently I did the layout using ReportLab/platypus and somehow (can't find the piece of code that did it) got the PDF output into a widget (pixmap?) which I just passed into QPrinter (scaled by (.8, .8) for some reason). I'm not sure how I did the PDF-widget stuff. I was using the KDE PDF viewer (as a KPart) for previewing, but I don't think that's how it was done. At any rate, I didn't have any trouble getting good quality output from QPrinter. There were only 5 or 6 lines of actual QPrinter code - I'd forgotten that I even used it. All of the PDF layout was in inches. KDE (kdeprint in kdelibs) basically uses an extended QPrinter (KPrinter) for printing - you might look at the kdeprint code or the code for apps like KWrite or KWord and see how they do it. There is a kdeprint module for PyKDE, but I haven't done much with it - no examples yet. I wish I could be more helpful, but I haven't looked at the subject for quite a while and can't do the digging at the moment. I'm still using a pretty kludgy system for forms printing myself. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Printing (General)
On 11-Mar-03 Ricardo Javier Cardenes Medina wrote: If they end implementing a good table support, then I could change my mind, but not now. If I had to pick the features most lacking in Linux widget sets or Linux in general it would have to be report generation and a good table widget (inplace editing, good navigation but with clean redraws/flicker-free, support virtualizing a large number of rows like Delphi tables do, etc). Qt (and GTK last time I looked) have improved but still fall short in my opinion. Either one would be a good project - unfortunately I can't keep up with the projects I'm doing now. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] getText() fix from 2002/05/15
On 05-Mar-03 Eli Carter wrote: I'm running RH7.3 + updates. One of the wonderful things about that distribution is PyQt-3.1-2 has a bug with QInputDialog.getText(). Namely, the 'parent' argument always complains of invalid type. I found: http://www.river-bank.demon.co.uk/download/snapshots/PyQt/ChangeLo g which has: 2002/05/15 11:31:23 phil Fixed a bug in QInputDialog.getText() for Qt3. apparently between releases 3.2.2 and 3.2.4. I want that fix, but I can't seem to find the source for those older versions. :( I can find the latestgreatest, and the various versions RH shipped, but not those. Nor have I found the delta that corresponds to the changelog entry. freshmeat isn't helpful because all the different version links point to river-bank. Is there a site somewhere that I missed? I really just want to make that change and rebuild... :/ I guess I'll see if I can guess at changes in the mean time... The current Qt version should build on RH7.3 with whatever Qt version you have (=1.42). Since you'll have to rebuild all of PyQt anyway, that isn't any more difficult (you'll need the corresponding sip version in any case). In fact the newer versions will build about 80% faster. The other alternative is to get the latest version an compare qinputdialog.sip to the version you have and see what changed. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] Install problem
On 24-Feb-03 Tom Chance wrote: Hello, I've just downloaded PyKDE, and tried to run the build script, but it exited with the following error trace: [EMAIL PROTECTED] PyKDE-3.3.2 $ python build.py Building PyKDE 3.3 for Python 2.2.2 on linux2. /usr/lib/python2.2/site-packages is the PyKDE installation directory. /usr/include/python2.2 contains Python.h. /usr/bin/sip will be used as the SIP code generator. /usr/include/python2.2 contains sipQt.h. /usr/lib/python2.2/site-packages contains the SIP module. /usr/qt/3 is the Qt base directory. /usr/qt/3/include contains qglobal.h. Qt 3.1.0 is being used. /usr/kde/3.1 is the KDE base directory. /usr/kde/3.1/include contains kdeversion.h. KDE 3.1.0 is being used. ^^ /usr/qt/3/bin/qmake will be used to generate Makefiles. The qt-mt Qt library was found. Qt thread support is enabled. Qt and KDE use compatible libs (threading) An internal error occured. Please report all the output from the program, including the following traceback, to [EMAIL PROTECTED] Traceback (most recent call last): File build.py, line 1413, in ? main(sys.argv) File build.py, line 1337, in main installChecks() File build.py, line 809, in installChecks checkKDELibrary() File build.py, line 635, in checkKDELibrary ml = modList [str (kdeVersion) [0:2]] KeyError: 31 I've got SIP and PyQT versions 3.5. Would that be the problem? Nope - the problem is PyKDE support for KDE 3.1 hasn't been released yet. PyKDE-3.3.2 will work with sip/PyQt 3.5 but won't work with KDE 3.0.4. If I get lucky, 3.1 support will be available in a couple weeks. At the moment it doesn't appear I'm going to be lucky, so it'll probably be a little longer than that. It would also be nice if instead of giving you the incomprehensible error messages above, build.py told you what the problem actually was, so I'll add that to the todo list for the next release. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] Some fundamentals
On 25-Feb-03 Tom Chance wrote: I've only just started out with PyQt, so please bear with me as I ask some boring questions :) I've been reading through the book GUI Programming with Python: QT Edition by Boudewijn Rempt online (the paper copy is just too expensive for a poorly student like me :-), and though it covers a lot of ground, it's written in a very confusing order, jumping around between ideas. I'm getting a bit lost trying to write a fairly simple application. When I'm confident enough, and I've finished my PyGame tutorial, I'll try my hand at writing a PyQt tutorial :) Anyway, enough rambling. I'm using Qt Designer to create my GUI, and I'm then importing the class in my main program file. At the moment, the main program file contains one class that inherits the GUI class, and that contains all my functions. I'm sure this isn't the best way to do things - I'm used to creating multiple classes, each one for a different task, and it seems a little messy having all my function code in one class. What's the best way of laying out the code? Why, the way that works of course :) Also, I'm struggling with connecting signals and slots. I understand the principle, and I'm getting the hang of working wiht Qt Designer and my code to create empty functions in Designer, and then create the actual functions in my main code, but I don't really understand the signal parameter in a connection. The basic connect function looks like (see QObject::connect in the Qt docs) in C++: connect (q1, sig, q2, slot); q1 = some QObject descendant (sender) sig = some signal emitted by q1 q2 = some other QObject descendant (receiver) slot = some member function that can receive sig 'sig' and 'slot' also have to agree on the number and type of parameters being passed. q1 and q2 are pointers, sig and slot are strings (char *). 'connect' is attached to some QObject subclass instance, eg: someObject-connect (...) in Python/PyQt: from qt import ..., SIGNAL, ... # DON'T FORGET THIS ... someObject.connect (q1, SIGNAL (sig ()), self.slot) (note only 3 args instead of the 4 in C++) Just like in C++, the signal name (sig) needs to be a string, but thanks to the magic of sip, you can simply specify the method that receives the signal (the slot) as above. Usually it's in the current class (hence the 'self') but doesn't have to be, and of course it probably won't be named 'slot' either. And again, 'connect' is a method attached to some instance, eg: someObject.connect (). E.g. I can guess what pressed(QListViewItem*) means? But why the QListViewItem with an asterisk? And what really confuses me is the int, const Qstring stuff. What do they signify, and why are they in the signal for a rightButtonClicked(), whilst clicked() has no parameters, and pressed only has QListViewItem? The 'clicked()' signal doesn't pass any parameters to it's corresponding slot(s), but 'pressed (QListViewItem *)' does (there are also overloaded versions of 'pressed' that pass additional parameters, so the argument keeps track of which 'pressed' signal you're specifying too). In the example above the signal/slot pair involves no argument passing, so there's nothing inside the () after sig. For pressed (QListViewItem *) the 'pressed' signal passes a QListViewItem pointer (hence the '*') in C++. In Python it will pass a QListViewItem instance (no pointers in Python of course). In either case, the slot (which you'll probably write) has to be of the form: C++: SomeClass::slotPressed (QListViewItem *listViewItem); Python: class SomeClass: def slotPressed (self, listViewItem): where 'listViewItem' expects a QListViewItem instance. In this case it's the QListViewItem that was pressed, so you can identify what the user clicked on; for a typical QPushButton press, you already know that because the slot is connected to only one button. Some of the other buttons (toolbar buttons for example) emit a 'clicked' signal that passes an int which is the index of the button pressed, so you can identify which button on the toolbar the user pressed. In Python/PyQt you need the C++ notation in the 'connect' call because Qt is written in C++, and that's where all of the actual work gets done. You're communicating (through Python and sip) a connection that's going to be implemented at the C++ level, and C++ cares whether it's a reference to a QListViewItem (no '*') or a pointer to a QListViewItem (QListViewItem *). There's a little more to it than that, but I'm far from an expert on the actual machinery. If you don't know the difference between a reference and a pointer: a reference is the actual object, a pointer is the address of the actual object - C++ uses both, Python only uses references (or instances). So for any signal in the Qt docs, you just specify the signal's declaration string, but drop any argument names or return type (always 'void' anyway, I believe). For example, the Qt docs
Re: [PyKDE] PyQt - getting unexpected async reply in threaded ap
On 23-Feb-03 Nicholas John Murison wrote: As far as I can remember, somewhere in the PyQt it says there should be a global qApp variable. However, my code can't seem to find it, so I've passed on the object through constructor parameters to the threads. This seems to be working, and I hope it is the right way to go about these kind of things. You should be able to access qApp if you just do: from qt import qApp or if you do (not the best form): from qt import * See for example application.py in the examples3/ subdirectory. (Just as a side note: current versions of PyKDE don't implement the equivalent kApp variable because it was causing a compilation problem; PyKDE does implement the static KApplication.kApplication() which can be called from any module and will return the program's KApplication instance) Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] Problems building pyKDE 3.3.2 on RedHat 8.0
On 20-Feb-03 Gary Cramblitt wrote: I am trying to build and install the following packages, but encountering problems. PyQt-x11-gpl-3.5.tar.gz sip-x11-gpl-3.5.tar.gz PyKDE-3.3.2-3.tar.gz My system is RedHat 8.0, Qt: 3.0.5, KDE: 3.0.3-8.3 Red Hat, Python: 2.2.1. Here is what I did. I unpacked each of the 3 packages above to /usr/local. I noted in the README files that environment variable KDEDIR is supposed to be defined. On my system, it is not. Hmmm, why not? That seems to be a trend with distributions - SuSE no longer defines it either. Worse, the following directory structure is expected $KDEDIR/lib $KDEDIR/include but apparently on my RH system, I have /usr/lib/kde3 /usr/include/kde Notice how the directories are inverted from what is expected. I note on the web that most systems have KDEDIR pointing to /opt/kde, but my /opt directory is empty, so I do the following commands: mkdir /opt/kde ln -s /usr/lib /opt/kde/lib ln -s /usr/include/kde /opt/kde/include export KDEDIR=/opt/kde Good solution. The KDEDIR export is only needed to build. I also note that README's say I should use -lqt-mt when building (because I have KDE 3). What is this? There are two versions of the Qt lib - libqt is un-threaded and libqt-mt is threaded. KDE 2.x.x (as normally compiled) will only work with libqt, KDE 3.x.x will only work with libqt-mt. PyQt will work with either lib, but PyKDE requires the the Qt lib that matches the KDE version. If you use the wrong KDE/Qt combination, everything will compile/link/install, but nothing will run. Anyway, I continue with the following commands (as su) with no apparent errors: cd /usr/local/PyQt-x11-gpl-3.5 python build.py -lqt-mt -c make make install cd /usr/local/sip-x11-gpl-3.5 python build.py -lqt-mt make make install cd /usr/local/PyKDE-3.3.2 python build.py -lqt-mt -c You should build sip first, then PyQt, and then PyKDE. If the sequence above is what you actually did, you built PyQt with the version of sip that comes with RH 8.0 (not likely 3.5), and then built PyKDE with sip 3.5 but probably against the PyQt sip files that came with RH 8.0 (also probably not 3.5). I don't believe that a normal PyQt install will put any files in /usr/share/sip/qt/ - I'd expect to find them in /usr/local/PyQt-x11-gpl-3.5/sip from the above. (locate won't see them until updatedb is run again) Just like the qt/qt-mt situation above, this stuff will often compile and link with completely wrong sets of files, but then won't work when you try to run something. Try the following: 1. run sip -V -- you should see 3.5 2. In the Python interpreter, try 'import qt'; if that works, try 'import dcop' and 'import kdecore' (kdeui depends on all 3 of those). I'm guessing none of those will work either. 3. Try some of the example programs from PyQt examples3/ directory. If PyQt works (import qt and examples), there's some other problem related to PyKDE. If PyQt doesn't work, you should be able to rebuild PyQt (if the sip version reports correctly) and then rebuild PyKDE with the correct path in the -v switch. If the sip version doesn't report correctly, you'll need to uninstall sip (using rpm -e) and then rebuild sip, PyQt and finally PyKDE. Alternatively, you can find the version of sip you built above and make sure it's earlier in PATH than the RH version, and then rebuild PyQt and PyKDE. The last command says can't find PyQt()/sip modules. I look in the build.py code and see that it is looking for qtmod.sip. Locate command reports /usr/share/sip/qt/qtmod.sip, so I continue with the following commands (with no apparent errors): python build.py -lqt-mt -c -v/usr/share/sip/qt/qtmod.sip make make install When I try some of the examples, I get an error. For example: $python Python 2.2.1 (#1, Aug 30 2002, 12:15:30) [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2 Type help, copyright, credits or license for more information. import kdeui Traceback (most recent call last): File stdin, line 1, in ? File /usr/lib/python2.2/site-packages/kdeui.py, line 73, in ? import libkdeuic ImportError: /usr/lib/python2.2/site-packages/libkdeuicmodule.so: undefined symbol: sipName_qt_del What did I do wrong? I am a newbie, so be gentle please. TIA You seem to be doing fine - you've solved most of the problems already. This is all pretty confusing at first (or in my case often still is). Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] PB to compile PyKDE-3.3.2
On 12-Feb-03 Gerard Breiner wrote: Indeed, it is about kde 2.2.1. I replaced in sip/kstddirs.sip kde 2.2.1 by kde 2.2.2 and run again build.py and make and make install. I'm not sure this will work unless you're also linking with KDE 2.2.2 libs - there's no way to resolve the reference to the method that doesn't exist in 2.2.1. Commenting or versioning out the method would be the better method. You can verify if this is a problem by doing an import kdecore in the interpreter. No more problems. test in interpreter python : from kdecore import kapp (ImportError: cannot import name kapp) kapp is defined as follows in kapp.h: #define kapp KApplication::kApplication() gcc 2.96 on RH has problems with the code sip generates for this, so kapp has been dropped from PyKDE. You can do from kdecore import KApplication and then: kapp = KApplication.kApplication () anywhere you need kapp in Python. from kdecore import DndURL (ImportError: cannot import name DndURL) I couldn't find a DndURL symbol in the KDE kdecore sources or anywhere in the kdelibs sources for KDE 2.2.1 from kdeui import KTreeList (ImportError: cannot import name KTreeList ) from kdeui import KTreeListItem (ImportError: cannot import name KTreeListItem ) from kdeui import KTabListBox (ImportError: cannot import name KTabListBox) I couldn't find either KTreeList, KTreeListItem or KTabListbox anywhere in kdeui or in the kdelibs sources for KDE 2.2.1. from kdeui import KMsgBox (ImportError: cannot import name KMsgBox) You probably want KMessageBox - I'm not aware of any KMsgBox class in the KDE libs. an idea please ? Are the above from KDE 1 by any chance? They look familiar. The KDE class ref docs are at: http://developer.kde.org/documentation/library/libraryref.html These will tell you what classes/methods are available in KDE for each version. The docs that accompany PyKDE will tell you which classes/methods are or are not implemented, and any changes in arguments or return values from the comparable C++ method. To test your installation, try to import each module you want to use in the interpreter. For example: import kdecore import kdeui import kio etc. Also try running: python pykless.py From the PyKDE-3.3.2/examples/ directory. The above will catch any link problems or other problems. If these work, then all of the classes and methods PyKDE provides bindings for should be accessible. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] PB to compile PyKDE-3.3.2
On 11-Feb-03 Gerard Breiner wrote: First of all, thank indeed for your help. Thanks for your patience and effort. First, what version of KDE are you running? It should be a 2.x.x it is exact It would help to know the specific version you're running - it looks like KDE 2.2.1 from the error below. You can find the version by looking in kapp.h (the value for KDE_VERSION) and should double-check by choosing Help | About KDE in any KDE app and checking that the version there matches the version in kapp.h. snip It appears Qt and PyKDE are now in sync, and you shouldn't have to rebuild PyQt again. *sipDo_KStandardDirs_calcResourceHash (PyObject *, PyObject *)': sipkdecoreKStandardDirs.cpp:79: no matching function for call to `KStandardDirs::calcResourceHash (char *, QString , bool)' In the kstddirs.sip file: %If ( KDE_2_2_1 - ) Q_UINT32 calcResourceHash (const char*, const QString, bool) const; %End The first line should be: %If ( KDE_2_2_2 - ) as this method doesn't appear until KDE 2.2.2. It looks like you have KDE 2.2.1 and are catching this error. Hopefully there aren't any more errors like this. If you find more no matching function errors, you check the corresponding KDE h file for the function and if it's not there, use the same fix as above. You can edit the sip file with any text editor, and then re-run build.py. Alternatively, you can comment out (//) the three lines above from %If ... to %End. If this isn't the problem, then you might be having some problems with build.py finding the correct KDE version, and we can troubleshoot that instead. The build test for this version of PyKDE was against KDE 2.2.2, so the error above slipped by. Sorry for all the difficulties you've had. I hope this is the last one, but if not I'll be happy to keep helping. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] PB to compile PyKDE-3.3.2
On 10-Feb-03 Gerard Breiner wrote:
First of all, my platform is Linux RedHat 7.2 with Python 2.2.2
I installed :
sip-x11-gpl-3.5
PyQt-x11-gpl-3.5
I tried to install PyKDE-3.3.2
Here what i did :
python ./build.py -t /usr/include/kde -s
/usr/local/lib/python2.2/site-packages/ -v
/home/admin/PyQt-x11-gpl-3.5/sip
No problem.
make.
--
cd kdecore; /usr/bin/make
make[1]: Entering directory `/home/admin/PyKDE-3.3.2/kdecore'
g++ -c -pipe -O2 -fPIC -DSIP_MAKE_MODULE_DLL -DNO_DEBUG
-fno-exceptions -I-I -I../extraH -I.
-I/usr/local/include/python2.2 -I/usr/include/kde
-I/usr/lib/qt-2.3.1/include -o kdecorecmodule.o
kdecorecmodule.cpp
In file included from sip/kstyle.sip:42,
from kdecorecmodule.cpp:129:
/usr/include/kde/kstyle.h:38: parse error before `{'
/usr/include/kde/kstyle.h:39: non-member function `className ()'
cannot
--
---
Where is the problem ?
Must i update KDE or PyKDE-3.3.2 has a bug ?
First, what version of KDE are you running? It should be a 2.x.x
version, as KStyle is in the kdefx module for KDE = 3.0.
PyKDE-3.3.2 supports KDE down to KDE 2.1.1, so that shouldn't be a
problem.
Second, some versions of Qt are compiled with some of the Q*Style
options missing. In this case, KStyle is a subclass of
QPlatinumStyle, so open the python interpreter and try:
from qt import QPlatinumStyle
My guess is that won't work - if it doesn't, it means you'll need
to recompile Qt with the correct feature set if you want to use
PyKDE as is. You'd also need to recompile PyQt in that case.
Otherwise you can try modifying PyKDE: in the subdirectory
PyKDE-3.3.2/sip/kde2* (kde21 or kde22 depending on your KDE
version), you can comment out the %Include kstyle.sip in
kdecore.sip ('//' comment). I'm not sure what else depends on
KStyle, so you may have to comment out other stuff as well, or it
might not be possible to do this at all. You'll need to re-run
build.py, and if it's going to fail it should fail there.
Anybody else here recall any RH 7.2 problems?
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] PyKDE for KDE 3.1?
On 07-Feb-03 Bart Verwilst wrote: Do you have an ETA for a KDE 3.1 - compatible release for PyKDE? Can't wait for it ;o) No - I really don't. I'm revising the tools I use to build PyKDE and adding some additional testing. I'm pretty far along on both but still expect it to be at least another couple of weeks and maybe longer. I've been saying several weeks for a while now - I haven't been able to get to it much in the last week, but am hoping to a get a lot done later today and over the weekend. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] NewBie: Any KWidget without KApplication possible
On 04-Feb-03 Claus Schumacher wrote: I'm any absolue newbie in PyKDE. I already managed to program PyQt with QtDesigner according to the examples. Is it possible to inherit KWidget like KDatePicker in QApplication(s) instead of KApplication(s) Since all KDE widgets are subclasses of QWidget, it *might* be possible that *some* KDE widgets would work in a QApplication based program. HOWEVER, in the case of KDatePicker (and probably most other KDE widgets), the actual widget code depends on things like KInstance, KLocale, or other KDE classes that are instantiated through the contruction of KApplication. In the KDatePicker case (I tried it anyway), the app segfaults, and I'm guessing that's because dates depend on locale information (like format or translation of month names) and KDE widgets expect a KDE class or structure to exist that holds that information. KDE themes capability would add another possible incompatibility. I haven't looked at this extensively, but my guess is that to get it to work you'd end up duplicating the KApplication functionality. If you're familiar with C++, looking at the KDE source for KDatePicker (it's in kdelibs/kdeui) might help you write your own date picker class in Python/PyQt. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] an example of simple python scripting of Kspread?
On 01-Feb-03 blake wrote: I am running RH8.0 and KDE. I would like to have a python program call up Kspread, open a spreadsheet (or two), calculate the results and then save the result. This would seem like a simple task, but the several examples given for the PyKDE v3.3.2 package seem to emphasize writing a new application rather than manipulating an existing one (like Kword, kspread etc). Can anyone point me to any documentation that would have examples of doing such simple scipting? The PyKDE examples are KParts examples and probably not what you want. There are two possible ways I can see to accomplish what you're asking (there may be other ways too - be creative): 1. Use DCOP. PyKDE has support for DCOP, although I've never personally used it or tested it (it's mostly there for symbol resolution at the moment). I'm not sure that what's there is sufficient (but I think it is). Additionally, you can dig through the KDE docs and code (the KDE SDK I think) and look for examples of interfacing to DCOP via Python *without* PyKDE. Sorry for being vague, but I've never investigated this area much. 2. Write Python plugins for KSpread. I've actually done this (for KSpread 1.1) and it's extremely cool. I've also just sent some old crappy code off (this morning in fact) to a KSpread developer who requested it, but I think he has something different in mind. This requires coding some C++, but isn't too hard. The code I did allowed a) scripting of KSpread via Python, which requires a wrapper for KSpread classes and Python bindings for the wrapper, and b) writing KSpread formulas in Python - eg put =someFormula (x) in a cell, which doesn't require a wrapper or bindings - just a fairly simple (after you spend a few weeks deciphering KSpread) pair of plugins (one for the formula mechanism and one for the Python interpreter). Note that you *can't* use PyKDE to write KDE plugins, because the KDE plugin mechanism requires a libtool library (there may be ways around that too however). The code I did was only for KSpread 1.1 - won't work at all with later versions because the KSpread internals changed significantly. At the moment I'm working on PyKDE for KDE 3.1 full time, along with a releated project. KSpread 1.3 (with yet more interface changes, I'm told) will be out around April, and Python itself looks like it will switch from a static (.a) lib to dynamic (.so) some time soon, so I'll be digging back into this then I hope. Otherwise, if you can't wait, understand C++ fairly well and want to dig through some bad code, I'll be happy to send you what I have. Just drop me an email directly. The tarball is about 600KB, probably won't compile, and won't work if it does. Or look into DCOP - unfortunately the KDE docs seem a little sparse though. Just to be fair, I believe this is supposed to be possible already with Gnumeric (although I've never tried that either). OpenOffice also has some stuff about Python scripting, but last time I looked it was also vaporware (similar to DCOP, too, I think). I think this would be a significant, important addition to KDE and wish I had time to get to it sooner. I'll get to it eventually if no one else does. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] KDE 3.1 and PyKDE
I noticed KDE 3.1 was finally released yesterday/today. To answer the inevitable question: PyKDE will have support for KDE 3.1, hopefully fairly soon. As I mentioned a while ago, I'm re-working the tools that I use to generate sip files for PyKDE. This has been going nicely - I've reached the point where I can generate PyKDE for *a* version of KDE almost perfectly. The next step is to be able to generate PyKDE for *all* supported versions of KDE (2.1.1 - 3.1), and that will take at least several weeks. The new tools have pointed up a few bugs in previous KDE versions, and in reviewing the code I've found some more bugs in the handwritten stuff - most not show-stoppers, but serious enough to make me want to do further testing and bug-fixing. I'm in the process of doing that right now and should be done in a day or two, at which time I'll move on to generating PyKDE for the rest of the KDE versions. The next release of PyKDE will require sip 3.5 and support KDE from 2.1.1 through 3.1. This will be the *last* release that supports any KDE 2.x.x version - subsequent releases will support KDE 3.0 forward, similar to Phil's plans for PyQt and sip 4. The next (KDE3.1) release of PyKDE will also be under the GPL license, as opposed to the present MIT-style license - let me know if that's a problem for anybody. It will include more comprehensive examples (at least enough to put all of the various widgets on a screen, but probably not all of the connections and functionality for all of them), testing of handwritten code to the extent practical (some stuff just requires too much additional code to test, and isn't likely to be used by many people anyway), and at least some templates for constructing applications (I have 4 or 5 done already) and code snippets for some of the more unusual features (I've only done one so far, but plan to accumulate more as time goes by) Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] How to inherit from QWidget
On 20-Jan-03 Paul F. Kunz wrote: I have a class, QtViewWidget which in C++ in herits from QWidget and class in my C++ library. How do I tell SIP to use QWidget from PyQt instead of creating a local QWidget in my build directory? Are you using sip to write bindings for your C++ lib? In that case you need to: 1. %Import qtmod.sip before your list of %Includes for your own files 2. When you run sip to generate code for the bindings, add a -I switch with the path to qtmod.sip, for example: sip ... -I /usr/local/PyQt/sip ... 3. For gcc, add a -l qtcmodule wherever you specify the libs to be linked with your module (and -L ...python/site-packages or wherever libqtcmodule.so is located if you don't already have that), and a -I for the path to the Qt h files (not the same path as in (2)) That will also add a bunch of sipqt*.h files to the directory where your sip-generated C++ code is located. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] How to inherit from QWidget
On 20-Jan-03 Paul F. Kunz wrote: On Mon, 20 Jan 2003 13:02:06 -0800 (PST), Jim Bublitz [EMAIL PROTECTED] said: That will also add a bunch of sipqt*.h files to the directory where your sip-generated C++ code is located. It also generated sipsihippoProxysihippo.h (sihippo is the name of my module. Do I need to moc that file and compile the generated file? Yes, it should have a Q_OBJECT line in it. You can steal the code to do it from PyQt/qt/Makefile. If you build the way PyQt and PyKDE do, it all happens automatically and I'm not really sure if tmake/qmake generate that or if it's in the build script. It hasn't broken yet, so I haven't worried about it. Older versions of PyQt/PyKDE (using autoconf) are set up to allow sip to generate the Makefile (-m switch), and include code to insert this in the Makefile. Using -m with qmake, the template for the Makefile (see the end of qtmod.sip, for example) doesn't need to worry about this any more. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] pykde.sourceforge.net
On 16-Jan-03 Jonathan Gardner wrote: On Thursday 16 January 2003 07:27, Hans-Peter Jansen wrote: Jonathan and Jim are the project managers there. Jonathan, Jim, what do you think about a contribution package section. I think it is a great idea. I think it is necessary for wide-spread acceptance of PyQt and PyKDE. Our goal is world domination, isn't it? ;-) My goal is to just get the next release done (I don't know if that deserves a :) or :( ) I thought this was great software back when it was 1.0, and a lot of stuff (including Phil's v 4.0 and Detlev's 'eric') is going to make it even better. I'd like to see sip, PyQt and PyKDE get wider use and recognition. I probably average privately an inquiry per month from people who want to build on top of PyQt/PyKDE, but a lot of that is still proprietary stuff. That's in addition to stuff like Gerard's package and some other things on sf that occasionally get mentioned here. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] pykde.sourceforge.net
On 16-Jan-03 Jonathan Gardner wrote: On Thursday 16 January 2003 07:26, Phil Thompson wrote: I can offer web space, but there is still the problem that a front end needs to be coded up. I have the skills, but not the time. Jim, Thanks for the offer. Please note that it's Phil's offer -- I'm not that generous :) (Actually I don't have any web space to offer) Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] sip
On 10-Jan-03 Jason Lee wrote:
I hope this is the right place. The Riverbank Computing web page
said it was, so...
I'm new to sip. I've been toying with swig, and haven't gotten
boost to run. I'm trying to get a Python wrapper for a C++
library (duh :), but I'm having trouble setting up my .sip. If
I have an empty class, things work fine.
If the class is derived from base classes, remove
the access-specifiers:
class someClass : public baseClass
in the sip file:
class someClass : baseClass
Once I start adding lines from the header file, I start getting
parse errors. The lines that seem to be causing problems are
definitions of functions pointers (
static void(*clearScreen)(uchar w, uchar h);
sip won't handle these automatically - you need to provide
handwritten code and I'm not sure how to do that in this case.
I've reposted this as a separate message, since it would be helpful
for me to learn how to do it also.
or struct declarations. The odd thing about the struct,
though, is that if it's empty, it's fine. Once I
add anything to to (e.g., uchar R,G,B,Alpha;), I get a parse
error.
The easiest way to handle structs is as a class:
struct someStruct
{
uchar R, G, B, alpha;
};
can be done as:
class someStruct
{
public:
uchar R;
uchar G;
uchar B;
uchar alpha;
};
You need to add public because the default access type for
structs is public, while the default for classes is private (and
that's about the only difference between the two). It may be that
newer versions of sip now handle struct correctly, and the
problem may be with the list in the declaration as opposed to
declaring each variable individually. The class method above
should work though.
It also errors out if I put a const int declaration outside any
struct or class scope.
I'm not sure what you mean here - global variable? It should work
OK, although I'm not sure if you can set the value of a global
variable from Python.
I'm sure I'm missing something fundamental, but the docs aren't
helpful, and the PyQT .sips are a little overwhelming for a
newbie. :)
You're actually being too kind here - the documentation situation
is pretty poor. Phil will be providing better docs with sip 4.0.
I've also volunteered to write a tutorial for sip, and there are
other things in the works to try to make sip easier to use.
Unfortunately all of this will occur sometime in the future, which
isn't a big help to you now.
Does anyone have any pointers as to what I'm doing wrong? I'd
appreciate the help.
BTW, if this is the wrong list, I apologize. It seems to be,
based on the web page, but if it's not, I'll gladly take my
question somewhere else.
You're in the right place - please feel free to post any questions
you need answers to. PyQt is probably the best place to look for
most answers - compare some .h file to a corresponding .sip file.
The %If ... %End stuff is just versioning/platform/feature stuff,
roughly equivalent to #ifdef in C/C++. Most of the things you're
asking about aren't used in PyQt however, so about the only way
to get answers for those right now is to ask here.
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] submenus in PyKDE
On 04-Jan-03 Gordon Tyler wrote: On January 4, 2003 01:51 pm, Jรฉrรดme Martin wrote: Is some one have an example to create a submenu with PyKDE. My menu are currently created with KAction/KStdAction. fileMenu = QPopupMenu(self) someAction.addTo(fileMenu) submenu = QPopupMenu(self) anotherAction.addTo(submenu) fileMenu.insertItem(Submenu, submenu) You can also look at the KDE docs for KAction and KActionMenu. The latter lets you build a submenu of KActions. Also see KSelectAction. The KDE 3.0 Class Reference is available at: http://developer.kde.org/documentation/library/3.0-api/classref/ind ex.html Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] QListView(Item) subclass insertItem strange behaviou
On 04-Jan-03 marvelan L wrote: The problem is that I need to access my own added methods in MyList when insertItem is called. But it seems that it is called with a object of the base class and not my specialisation class MyList. Since it's printing, it would seem that the overloaded methods are being called correctly. You can test which object (base or sub class) is actually instantiated by calling a subclass-only method using the object in question. If the object is of the base class type, the call to a subclass method will fail. I'm not sure how __class__ works with PyQt classes, but if it uses QObject.className in some way, it's unlikely to report a Python-created subclass correctly. From your post, it doesn't appear that what __class__ returns is important, but just that the correct object type is instantiated. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] KMimeType.findByPath return value
On 03-Jan-03 Daniel Naber wrote:
On Thursday 02 January 2003 21:52, you wrote:
Can you use KTrader instead?
Not really, it seems the name() problem also appears with
KMimeType.findByURL() and findByPath(), these also
sometimes(?!) return random characters. Sometimes
the first call to those functions works, but the second returns
crap or crashes. This only happens if I click on the same file
a second time in my GUI, the result is then different. I cannot
reproduce this with a test case where the function is simply
called twice - this works.
If you can try an equivalent C++ version, that would be helpful.
This seems to work:
QString name =
KMimeType::findByURL(KURL(/home/dnaber/desktopdig/test/test1.html
))-name();
printf(name=%s\n, name.latin1());
KService::Ptr ptr = KServiceTypeProfile::preferredService(name,
Application);
QString name2 = ptr-name();
printf(name2=%s\n, name2.latin1());
if( ptr-isValid() ) {
printf(isValid);
} else {
printf(not isValid());
}
The output is correct:
name=text/html
name2=Konqueror
isValid
For now I will avoid all the problems by disabling the feature
that I'm trying to implememt (namely a security warning like
Do you want to open the file with %s % offer.name()).
Nonetheless, it would be great to get this fixed, as it's
important for the software's security. Thanks for all your
support so far.
Thanks for the C++ test - that's a big help. It appears that the
problem is with PyKDE. I'll get to it as soon as I can - hopefully
within the next week.
I wasn't able to get any result back for name() - no crash at that
point in the program, but a crash on exit. There are several pieces
of handwritten code to handle the SharedPtr template stuff for
those classes and the error is probably somewhere in that code,
possibly an incorrect assignment or something getting freed in the
wrong place, Both Python and the SharedPtr stuff use reference
counting.
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] SIP Roadmap
On 02-Jan-03 Phil Thompson wrote: For those interested I've added a SIP Roadmap to the website at http://www.riverbankcomputing.co.uk/sip/roadmap.php which describes the main objectives and features for SIP v4. Comments welcome. I think it looks great - I especially like the Python 2.2 features as I switched completely to 2.2 quite a while ago. I'm not opposed to the Qt3.0 cutoff either - that will make it necessary to cutoff PyKDE at 3.0 also. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] KMimeType.findByPath return value
On 02-Jan-03 Daniel Naber wrote: On Thursday 02 January 2003 01:56, you wrote: KServiceTypeProfile.preferredService takes a QString as its first argument, so you should use mimetype instead of mimestr. Then the offer is None, even for things like text/html. If I ask for offers for text/html (- as a python string), I get the problem described in the mail before, i.e. the broken result of name(). offer.name(). I was using an older value of PyKDE which didn't use findByPath, so that may have been my problem. findByPath() and findByURL() doesn't make a difference for me regarding this problem. I get the same problem - name() is an empty string, while isValid() returns True. I also get None for library(), but type() returns correctly. Also note that in PyKDE, exec() was not renamed (it clashes with the Python keyword), so it's not accessible. Can you use KTrader instead? There is a simple example in examples/pyParts.py, and more complete docs in the KDE class reference (kio - KTrader). At the moment I can't tell if the problem is with KDE or PyKDE, and I'm going to be pretty backed up for a while. I'll spare you the gory details, but I'm about ready to scream. If you can try an equivalent C++ version, that would be helpful. Otherwise I'll try to sort it out as soon as I can get to it. The only other thing I can think of is that the blank name has something to do with KSycoca, but I have no idea what. Beyond that, it's an error in code someplace but may take some time to find out where. Sorry I can't be more helpful at the moment. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] KMimeType.findByPath return value
On 01-Jan-03 Daniel Naber wrote: On Tuesday 31 December 2002 07:12, Jim Bublitz wrote: name() returns a QString, so print self.mimetype.latin1() should print the appication/x-shellscript and you should be able to use the value of self.mimetype.latin1() as a Python string. Yes, that works but now there's another problem, see below. One of the problems was, I think, that findByPath() never returns None, even if you ask for a file that doesn't exist. It seems instead you get some undefined result. But this is a problem with the KDE API, which never returns 0 (that's what the KDE documentation says). Anyway, I think I've now built a small test case which crashes. I've attached it, see the comment marked with ***. Make sure that the filename in self.url really exists. I get KCrash: crashing but the crash dialog doesn't appear so I don't have a backtrace. Actually it doesn't always crash, but at least the problem that the returned name().latin1() contains random characters appears each time. KServiceTypeProfile.preferredService takes a QString as its first argument, so you should use mimetype instead of mimestr. That took care of the crash for me, but I got an odd value for offer.name(). I was using an older value of PyKDE which didn't use findByPath, so that may have been my problem. Let me know if that fixes your problem. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] KMimeType.findByPath return value
On 30-Dec-02 Daniel Naber wrote: the documentaton says that KMimeType.findByURL() returns an instance of a KService, I assume the same is true for KMimeType.findByPath(). However, how can I simply get the service's name? I can print it like this: The PyKDE documentation is incorrect, although it doesn't make a lot of difference in this case. findByURL/findByPath return a KMimeType instance, which should still have a usable name() method (inherited from KServiceType). self.mimetype = KMimeType.findByPath(url).name() print mimetype=%s % self.mimetype Output is something like mimetype=application/x-shellscript, but this is still of type 'instance' and thus cannot be used for KServiceTypeProfile.preferredService(). How can I make the name a string? str() around the right side of the self.mimetype=... leads to a crash where the KDE crash handler pops up (backtrace below). name() returns a QString, so print self.mimetype.latin1() should print the appication/x-shellscript and you should be able to use the value of self.mimetype.latin1() as a Python string. The type instance you get for self.mimetype should be a QString instance, and since it may be Unicode you need the latin1 conversion. That may be why str() fails, although if % works I don't see why str() would fail. I'm using the 20021122 snapshot RPMs for Suse 8.1 I haven't tested with either of those, but I don't expect it should be a problem, especially if you can get something like KApplication working. Try the latin1() conversion and if that doesn't work, repost and I'll check into it further (can't get to it until late Wed or Thur anyway). Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] Opinions on pyuic Custom Widget Support
On 14-Dec-02 Phil Thompson wrote: A more generic, think about it for 2 minutes, solution is to allow Python code to be embedded in the Comment field of the Form Settings dialog. Any line beginning with Python: will be copied to the generated module. This is then completely flexible. Before I go ahead and implement this, does anybody have any better suggestions? Or additional things that could be done for common cases (like support for PyKDE widgets). I believe everything PyKDE needs can be done that way except the change from QApplication to KApplication, which is a pretty simple edit. It sounds like a good solution to me (having thought about it for 2 minutes also). Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Re: [C++-sig] Can boost.python and PyQt be used toge
On 13-Dec-02 Paul F. Kunz wrote: On Wed, 11 Dec 2002 14:15:17 -0500, David Abrahams [EMAIL PROTECTED] said: I don't think that's really the right conclusion... or at least, it masks something much deeper. You might be right here. Although I got my Qt Window to work with PyQt by using SIP under Linux, I'm still having trouble under Windows. It is not Python crash however, it is something about QPainter being used on a device which already has a QPainter. Are you sure that you only have a single QApplication instance and that both Boost.Python and PyQt are referencing the same QApplication instance? That's QPainter related somewhat (if you try to instantiate a QWidget with no QApplication instance, the error will be from QPainter, for example). QApplication also sets up the event loop (there should be only one of those too). Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] PyKDE
On 13-Dec-02 Julian Rockey wrote: Is PyKDE being maintained? I'd be interested if a KDE 3.1 version is under development, as I'd like to try to integrate PyKDE/QT into KDevelop 3.0 (Gideon). You must be new here - people familiar with the list know better than to ask that question, because it always leads to a long, boring explanation (see below) In my (humble, obviously) opinion, Python as a scripting language could be as important to Unix/Linux as VB was to Windows (and I mean that as a good thing...) Have there ever been discussions about whether to release PyKDE/QT with KDE's kdebindings package? Long, Boring Explanation (I actually answer your questions somewhere near the end) PyKDE is indeed still being maintained. There won't be a new release until after KDE3.1 final is released. Here's a status update, a really long, boring explanation: For some time the sip files which sip uses to generate PyKDE have been generated automatically via a very poorly written program that produced a lot of errors on output, but still saved a immense number of hours. About a month ago, I started rewriting that program, and it is now a nice modular, actually debuggable, semi-documented tool. At the moment, it will automatically generate (except for some handwritten code) a complete set of sip files (which means a complete set of bindings more or less) from a set of h files for a lib. It has a few bugs, but nothing major that I'm aware of. However, to be useful for PyKDE, the program has to be able to do versioning - ie take a set of sip files from the previous release and mix in the h files from the current KDE release to produce a set of sip files that supports the current and all previous KDE releases (PyKDE for KDE 2.1.1-3.1 consists of a single set of sip files, just like PyQt does for its set of Qt versions/platforms). For reasons that would take even longer to explain, it makes sense to rebuild PyKDE from 2.1.1 forward. If the tool works, this isn't as bad as it sounds - once I get the first version (2.1.1) working, each additional version should really only take about half a day, especially with compile times as fast as they are now, and having built everything through 3.0.4 once already. So the point I'm at now is I have a set of sip files generated for KDE 2.1.1. I need to clean those up (mostly handwrite some code - actually cut and paste handwritten code from PyKDE-3.3.2) to get a buildable PyKDE for KDE 2.1.1 (about 2/3 done). Next I need to finish up the versioning code of the generator program, so that I can produce more or less automatically KDE 2.1.2 ... KDE 3.1. The time frame to complete that is a few weeks. I was shooting for before the holidays, but it now looks like perhaps just after the holidays. One big help will be that Phil just released sip/PyQt 3.5, so for once the KDE release will be after the last sip/PyQt update - in the past it has made sense to wait for the sip/PyQt release before releasing a new PyKDE. There is kind of a master plan to all this (subject to very much drastic change) that fits very well with your question about KDevelop and comparison to VB. I agree completely that Python + bindings could be far superior to VB for KDE in particular and Linux/BSD in general. My goals (in chronological order) are: Step 1. Release PyKDE for KDE 3.0.5 and KDE 3.1 - as soon after the 3.1 final release as possible. Step 2. Clean up my sip file generator program, document it, document sip generally as much as possible (probably update Wilken's docs if he doesn't mind and perhaps add a tutorial). Every few weeks someone posts to c.l.p asking about generating bindings for some lib or other (the last was a few days ago for OpenH323). There is at the moment no easy way to generate bindings (unless you're familiar with sip, which at present is largely undocumented, although a dream to use once you become familiar with it). The basic idea is that if you have a lib/set of h files to bind, you can write a short, simple project description file and the sip file generator will automatically produce a set of sip files which can be submitted to sip to generate the actual bindings. The generator will also produce all the ancilliary files: build.py, Makefiles, docs (in the current PyQt/PyKDE style) - everything except a small amount of handwritten code (which should be covered exhaustively in a tutorial or HOW-TO). If when this is working the people doing packaging can see a way to add scripts to generate RPMs and deb files, that would make it nearly perfect (except for all the bugs I've probably coded in already). Target date is late Q1/early Q2 (lots of docs to write). Note that if this works, future PyKDE releases should be achieveable in a few days after a KDE release. (2) now means that any C/C++ libs can be bound for Python - in theory it should be able to generate bindings for any KDE lib (not just the basic libs as now - arts, games, whatever), or even
Re: [PyKDE] Interfacing to C++ standard library
On 11-Dec-02 Torsten Marek wrote:
Jim Bublitz schrieb:
On 11-Dec-02 Paul F. Kunz wrote:
To complete my SIP based Python extension module, I need to
convert from C++ to Python and vica versa an std::vectordouble
and std::vectorstd::string. I found some hints in this
mailing list's archive dated 13 Apr 2002. Is there a better
source of information on how to proceed?
...
You'll might also need to use the same methods for std::string
to convert to/from either a Python string or QString if it's
used
outside the mapped type/member code for
std::vectorstd::string.
This is the mapping code for string:
%MappedType string
{
%HeaderCode
#include string
%End
%ConvertFromTypeCode
const char *s = sipCpp-c_str();
return PyString_FromString(s);
%End
%ConvertToTypeCode
// Allow a Python string whenever a string is expected.
if (sipIsErr == NULL)
return PyString_Check(sipPy);
if (sipPy == Py_None) {
*sipCppPtr = NULL;
return 0;
}
if (PyString_Check(sipPy)) {
*sipCppPtr = new string(PyString_AS_STRING(sipPy));
return 0;
}
*sipCppPtr = (string
*)sipForceConvertTo_string(sipPy,sipIsErr);
return 1;
%End
};
It should just need string being replaced by std::string and
sipForceConvertTo_string(...) renamed to
sipForceConvertTo_std_string(...), but I'm not really sure about
the naming scheme, so please try yourself, before I post
incorrect code.
Looks OK to me, but I'm not familiar with the std lib semantics. The
only change I would make is
%MappedType std::string
if that's how it's referenced in the code.
The std::vector types would be similar in style, although obviously
different Py* conversion functions and a little more involved,
since it's necessary to iterate over the lists.
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Seperate Qscintilla from PyQt
On 12-Dec-02 Ricardo Javier Cardenes Medina wrote: I'm even planning to split python-qt3 (which is a huge package) on several other packages, as not everyone need, say, qtgl, or qtsql. I appreciate all of those doing packaging enough that I wouldn't tell anyone what to do - this is just my opinion and nothing more. I appreciate that PyQt is large and PyKDE is even larger, however with the -c switch build times have become reasonable, and the amount of HD space the full packages take is not that great. My concern with splitting the packages is the possible creation of dependency problems for third-party developers - eg those people using PyQt of PyKDE to develop their packages. They should be able to count on a basic integral PyQt or PyKDE when distributing *their* packages. I'd prefer to avoid a situation similar to libc (hypothetically) making the socket functions optional. An app like eric may not have problems, but database apps (or even apps that peripherally use databases) will certainly expect qtsql, and apps that include 3D might expect qtgl. Similar dependencies might exist with PyKDE. I realize people can add the missing packages later if needed, but it's just one more missing dependency to satisfy and might also cause version problems, eg PyQt-3.3.2 installed without qtsql now needs qtsql, but only PyQt-3.5 version is easily available. Installing 3.5 might break user's PyQt-3.3.2 code for some obscure reason. It may not be a realistic enough concern to worry about, but it seems worth considering whether it's important or not. Just my 2 cents. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] menu icons
On 04-Dec-02 Eli Carter wrote: Ok, this is probably a dumb question, but... In kde3, I've noticed that there are some 'standard' icons used in the menus for things like 'Quit'. Is there a pre-made QIconSet or QPixmap to grab, or do I need to find the file and load from it? On a SuSE system, they're most likely under /opt/kde3/share/icons/. I'd expect a fairly similar location (except rooted somewhere other than /opt perhaps) for other distributions. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] menu icons
On 04-Dec-02 Richard Jones wrote: On Thu, 5 Dec 2002 9:28 am, Jim Bublitz wrote: On 04-Dec-02 Eli Carter wrote: Ok, this is probably a dumb question, but... In kde3, I've noticed that there are some 'standard' icons used in the menus for things like 'Quit'. Is there a pre-made QIconSet or QPixmap to grab, or do I need to find the file and load from it? On a SuSE system, they're most likely under /opt/kde3/share/icons/. I'd expect a fairly similar location (except rooted somewhere other than /opt perhaps) for other distributions. Don't the icons change according to the user's selected icon set? How do we hook into that? I'm not really sure - KIconLoader or KIconTheme (or both)? Also, I believe for the toolbar, KStdAction finds the icons automatically if you use that to set up icons and menus. Obviously, custom actions will require custom icons - I think the app's directory under kde3/share is searched for those unless you specify a different path. I haven't looked at this stuff in a while and couldn't find anything poking around quickly. I guess I'd start with the KStdAction and KAction docs and whatever UI design docs are on the KDE web site. I wasn't sure if the original post was in regard to using KDE icons with PyQt or PyKDE. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] about DCOP, QDataStream, , and
On 30-Nov-02 Me wrote:
Hi, I'm trying to figure out how to use the DCOP interface. The
KDE C++
examples make use of and , but how to do it with python? Is
there a work
around for this?
The example I'm working from has a part like so:
void MainWindow::bookLocation()
{
DCOPClient *client=kapp-dcopClient();
QByteArray params;
QDataStream stream(params, IO_WriteOnly);
stream location-text();
if (!client-send(p6-*, bookmarkList, add(QString),
params))
kdDebug() Error with DCOP\n;
}
How would I do that with python? Thanks for any help.
The short, quick, and unsatisfying answer is I don't know. I've
been aware that the DCOP interface in PyKDE *might* be incomplete,
but haven't looked much farther than that. I seem to recall that I
did see a way around this, but I'm not sure what it might be at the
moment. I'll look into it and try to have an answer in the next day
or two. Please post again if I don't get you an answer in that
timeframe.
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] about DCOP, QDataStream, , and
On 30-Nov-02 Jim Bublitz wrote:
On 30-Nov-02 Me wrote:
Hi, I'm trying to figure out how to use the DCOP interface. The
KDE C++
examples make use of and , but how to do it with python? Is
there a work
around for this?
The example I'm working from has a part like so:
void MainWindow::bookLocation()
{
DCOPClient *client=kapp-dcopClient();
QByteArray params;
QDataStream stream(params, IO_WriteOnly);
stream location-text();
if (!client-send(p6-*, bookmarkList, add(QString),
params))
kdDebug() Error with DCOP\n;
}
How would I do that with python? Thanks for any help.
The short, quick, and unsatisfying answer is I don't know. I've
been aware that the DCOP interface in PyKDE *might* be
incomplete, but haven't looked much farther than that. I seem to
recall that I did see a way around this, but I'm not sure what
it might be at the moment. I'll look into it and try to have an
answer in the next day or two. Please post again if I don't get
you an answer in that timeframe.
It looks like you should be able to use QDataStream.writeBytes
or QDataStream.writeRawBytes to put data on the stream. These
are declared in qdatastream.sip as:
QDataStream writeBytes(const char * /Array/,uint /ArraySize/);
QDataStream writeRawBytes(const char * /Array/,uint /ArraySize/);
I'm assuming the /.../ stuff (Phil ??) means that from Python you
only need to supply the char string and sip will compute the length
and pass it to Qt for you, eg:
stream.writeBytes (location.text())
(assuming location.text() returns a Python string or char * and NOT
a QString - you'll have to do conversion otherwise).
If that doesn't seem to work, then try adding the uint length
argument as well - just len(location.text()).
The kdDebug stream doesn't exist in PyKDE - you'll have to provide
your own error handling. Obviously I haven't tried any of this, so
let me know what fails if it doesn't work.
The other missing parts in DCOP will relate to IceConn messaging
stuff - off the top of my head, there didn't seem to be a good way
to extend the bindings to cover that as it's tied into X-Windows,
but I can look at it again if there's a need.
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Speed of derived objects
On 25-Nov-02 Vincent Wagelaar wrote: On Monday 25 November 2002 22:44, Hans-Peter Jansen wrote: [snip] Hopefully this example is nice enough? I think this is problably one of the few cases where you need to make an C++ implementation because of speed. It would be nice if calling (overloaded) methods in the next version of Python would be speedier!! On my computer it's about ten times slower than directly calling QListViewItem in both populating the listview and sorting. Phil might disagree, but I don't think there are major speed improvements available for the bindings. You're doing a lot of essentially invariant stuff in the paintCell and key methods however. Try something like: from qt import QListViewItem, QColorGroup, QColor Green = QColor (0, 155, 0) Red= QColor (200, 0, 0) Orange = QColor (255, 100, 0) class ColorListItem(QListViewItem): def __init__(self, *args): QListViewItem.__init__(self, *args) # this gives you a QColorGroup with everything # set to black, so you probably need to expand # this a little - could get tricky if you plan # to allow user changes in colors. I didn't see # any way to extract the color group info from # QListViewItem, but I didn't look very hard # either. self.colorGroup = QColorGroup () # might not need to do these - I think # they're correct, but might not be much # faster self.ptCell = QListViewItem.paintCell self.keyCall = QListViewItem.key try: self.pstr = float (str (self.text (0))) except: self.pstr = 0 self.keyVal = %015d % (self.pstr*100+10) if self.pstr == 0: color = Orange elif self.pstr 0: color = Green else: color = Red self.colorGroup.setColor (QColorGroup.Text, color) def paintCell (self, painter, qg, column, width, align): if column == 0: self.ptCell (self, painter, self.colorGroup,\ column, width, align) else: self.ptCell (self, painter, qg, column,\ width, align) def key (self, column, asc): if column == 0: return self.kevVal else: return self.keyCall(self, column, asc) I haven't tested this, but the basic idea should give you some speed improvement - hard to say how much. If the values for the QListViewItems can be changed, you'll need to break the stuff in __init__ into a separate method and re-calculate when the value changes (overload setText?). You also probably need a more involved setup for self.colorGroup (different ctor?), but you should only do that once. You could also do self.colorGroup as 3 different globals - one for each condition - but that'll make it harder to customize colors. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] ANN: Eric 3.0.0-alpha2 released
On 24-Nov-02 Detlev Offenbach wrote: Hi Trolls, Eric 3.0.0-alpha2 is available for download via Could you also post this to comp.lang.python? Or I will if it's inconvenient for you ... Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] ANN: Eric 3.0.0-alpha2 released
On 24-Nov-02 Jim Bublitz wrote: On 24-Nov-02 Detlev Offenbach wrote: Hi Trolls, Eric 3.0.0-alpha2 is available for download via Could you also post this to comp.lang.python? Or I will if it's inconvenient for you ... I guess I should have checked the newsgroup first :) Nevermind. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] paint() and getting out of corners
On 22-Nov-02 Rune Hansen wrote: As the title hints I've got serious problems trying to understand how to set color and font on a specific QListBoxItem. I would really appreciate a working example or at least better advice than RTFM ;-) It looks like the easiest way would be to derive a class from QListBoxText and overload QListBoxText.paint (QPainter). Modify the properties of QPainter to get the fonts and colors you want. class CustomListBoxText (QListBoxText): def __init__ (self, args): QListBoxText.__init__ (self, args) def paint (p): p.setFont (args) p.setPen (color) # or create new pen(s) as needed QListBoxText.paint (self, p) For QPainter you'll have to RTFM though :) QPainter has methods for setting the font and colors, and shouldn't be too difficult to figure out. If you can read C++ source, sometimes downloading the Qt source from TrollTech can be helpful (and sometimes not). Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] paint() and getting out of corners
On 22-Nov-02 Rune Hansen wrote: No matter how I shuffle this my app always segfaults on calling paint() I'm using stock RedHat 8.0 pyQt-3.3.2. I will try to compile the latest greatest pyQt tomorrow to see if it the segfault goes away. Post the code here if you still have a problem. If you can, try to reduce it to a small example that still exhibits the problem. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] Re: Anybody home?
On 21-Nov-02 Phil Thompson wrote: Strange. I haven't noticed anything from you other than your postings to the list - but I obviously noticed this one. It wasn't anything that important - I've been helping someone build some sip modules for a commercial widget derived from Qt, and a question came up about library naming that I couldn't find the answer to in the Python docs: We do something like: libname: libqtcmodule.so in qt.py: import libqtc But apparently libqtc.so will also work and ends up with either the same import statement or an as libqtc tacked on the end. I was just wondering what the rules were here, if any, or if you had a reference in the Py docs. I get several hundred emails a day which I read by scanning the subject line, so there is a danger of me ignoring something if it doesn't have an obvious reference to my stuff. Same here, but most of them sort to my wife :) A tip to people mailing be directly - put PyQt at the start of the subject. Noted. People have to try really, really hard to offend me - although it is possible. Guess I'll have to try harder :) Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] PyQT Programming Book [Thank you]....
On 23-Nov-02 Jack Neal wrote: I don't know if anyone on this list uses Komodo Do you have a URL you can post? Thanks for the favorable comments - this is a great group IMHO. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] Anybody home?
Phil - Are we having a mail problem again? Did I offend you? I sent a couple messages and haven't received a reply. I can post some additonal addresses here if my normal address is bouncing mail, or are you off some place again? Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] QTable, selections and moving column headers
On 19-Nov-02 greg Landrum wrote: [PyQt-3.3.2, qt-3.0.5, RH8.0, Python-2.2.1] The attached file constructs a simple widget using a QTable. It also attempts to: 1) limit selection to a single cell 2) allow moving of columns and rows as near as I can tell, neither 1) nor 2) work. Is this a known Qt problem (I couldn't find any reports of it) or a PyQt thing? setSelectionMode works, and you appear to it coded correctly. I've never used setRow/ColumnMovingEnabled. Usually I load the column and row labels into Python lists, set the number of rows and columns once from the list lengths, and then set all of the labels in a loop. I can't see why the extra calls would make a difference though. What kind of symptoms are you getting (eg nothing works at all, get full row selected instead of single cell, rows drag but don't drop, etc)? The only other thing I can think of at the moment is to make sure the QTable gets focus (look at focusPolicy, setFocus in the Qt docs). Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] crash: pure virtual function called
On 12-Nov-02 marvelan L wrote:
I have built an application with Qt 3.0.4 and PyQt 3.4.
From time to time I get a error message on stdout
saying pure virtual function call and then abort is called
and the program exits.
I suspect that this is from the PyQt bindings. Have anyone
seen this and know what to do about it?
Check the *Qt* docs and see if either:
1. One of the classes you're using is abstract
2. A method in a class you're using ends in = 0, for example:
virtual int someMethod (QWidget *parent) = 0;
(2) is an example of a pure virtual function. When a method like
(2) exists in a class, the class is abstract. When the class is
abstract, you can't instantiate it. You have to subclass the
abstract class and overload *all* of the pure virtual functions,
so for example:
C++ (Qt):
class SomeAbstractClass
{
public:
...
virtual int someMethod (QWidget *parent) = 0;
...
};
Python (your program):
-
class SomeClass (SomeAbstractClass):
...
def someMethod (self, parent):
do something here because the
pure virtual method probably
doesn't do anything
...
and def EVERY pure virtual function in the abstract class (usually
there are only a few at most, possibly only one).
If neither 1 or 2 is true, then you'll need to provide more
information about what your program is doing.
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] Qt shutting down the process/Python interpreter - ne
On 08-Nov-02 Michael Lauer wrote: Now, my question... is there something I can do at python level or is there something we can do at PyQt level to change this behaviour? If you call sys.exit() in Python it always raises a SystemExit exception. Does that happen here? If so, you can trap it and cancel it or whatever you need to do. Is there a way you can cause SystemExit to be raised? (I'm not sure if this happens at program termination without an explicit sys.exit() call). That might also be a solution for the other people with destructor-call problems. Then again, it might not. Alternatively, can you have soemthing set a flag if QApplication launches successfully? For example: app = QApplication (...) ... while True: app.exec_loop () if flag: break do something to fix whatever caused app.exec_loop() to exit early You can subclass QApplication or install a temporary eventHandler if necessary. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] ANN: Preview of Eric Version 3 available
On 25-Oct-02 Detlev Offenbach wrote: It's a long time now that a new version of eric was released. To let you know whats happening to eric and to see what can be expected from the next release please see http://www.die-offenbachs.de/detlev/eric3_preview_en.html Be prepared for a surprise. Wow. I was just looking at WingIDE a few minutes ago - I can (or can't) wait until this is available. Nice job. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Screenshots: PyQt/KDE Development-Portal
On 24-Oct-02 Konrad Hinsen wrote: Jim Bublitz [EMAIL PROTECTED] writes: Now that you mention it, I can't remeber every hearing liebchen at home, but definitely Schatz or Schatzie. Liebchen is the stereotypical Hollywood word used in dialog with German Interesting. It's rather archaic, I can't imagine anyone using it today. Perhaps in the early 20th century. Yeah, well my knowledge of German is pretty archaic too :) (although not quite *early* 20th century). I never expected to discuss German on a Python list :-) Nobody expects the German Inquisition ... Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] subclassing widgets contained in a QtDesigner form
On 24-Oct-02 Michael Ferraro wrote: I would like to sub-class a widget (QLabel for example) that I have placed (sized, colored, etc.) in QtDesigner in order to overide the mouseDoubleClickedEvent() . I realize I could modify the class generated by pyuic and change the QLabel to a MyLabel for each occurance but did not want to modify the files generated by pyuic I was wondering if there is some idomatic way of copying all the properties of a instance into a new one.without explicitly assigning them. An instance's __dict__ (for example label.__dict__) contains all of the class variables and their values (label.text is accessible as label.__dict__[text], or would be if it wasn't private in C++). However with PyQt class instances you need to modify the values stored in the underlying C++ object, so just replacing __dict__ won't do any good. The C++ values are the ones that appear on the screen. In fact, since most Qt data members are private, they're not directly accessible via Python under any circumstances (you'd need to use label.setText ()/label.text () to write or read the value). For the same reasons, playing around with something like copy constructors probably won't work either. There's a better solution at the end, however you could also try (as a general method): def myMouseDoubleClickEvent (s, e): # s receives 'self',e is a do stuff# QMouseEvent QLabel.mouseDoubleClickEvent (s, e) do more stuff label1.mouseDoubleClickEvent = myMouseDoubleClickEvent label2.mouseDoubleClickEvent = myMouseDoubleClickEvent etc. Here's a crude equivalent done in the Python interpreter: class a: ... def __init__ (self): pass ... def output (self, s): print s ... def d(self0, s): print Goodbye ... c = a() c.output (Hello) Hello a.output = d c.output (Hello) Goodbye also (using the original definition for class a): class e(a): pass ... c = e() c.output (Hello) Hello def f(self0, s): print Goodbye;a.output (self0, s) ... e.output=f c.output (Hello) Goodbye Hello In Python, you don't need to subclass to overload a method :) Since it's an event that you're working with, look at the Qt docs for QObject::installEventHandler instead - you don't really need to subclass to use that, and that's probably the best solution in this case. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Screenshots: PyQt/KDE Development-Portal
On 23-Oct-02 Marc Schmitt wrote: On Mittwoch, 23. Oktober 2002 16:51, Eli Carter wrote: Hmm... Py.Heaven does seem random... So here is an idea: I've long thought that the name 'PyQt' was backwards... it should be 'QtPy', because it sounds like cutie-pie (a term of endearment, for those not from around these parts ;) ) Anyway, it might be something Ehm, could you define cutie-pie in some other words please ? (my Longman DCE defines endearment as an action or word that expresses your love for someone, ... I just don't get it :) The name Py.Heaven is really more or less random. I wanted the tokens Py, Qt and KDE to appear within the name, but I found nothing sensible. My German is virtually non-existent any more, but it would be somewhat of a cross between liebchen and scho/ne Ma/dchen. Scho/n ~= cute - cutie (sounds like 'Q t'), which is sort of a diminutive, like adding -chen on the end of word auf Deutsch (??) It's more like baby talk. Sorry, I can't do umlauts, and my spelling is probably off too. (Babelfish was no help either) It's kind of like trying to translate one of my mother's favorite jokes (she was born in the US but grew up in a German speaking household): if you asked her Was ist los?, her reply was always Alles was nicht angebundant ist. In English that becomes What's wrong? - Everything that isn't tied down. It loses something in the translation. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Where What ?
On 23-Oct-02 Marc Schmitt wrote: On Dienstag, 22. Oktober 2002 21:16, Jim Bublitz wrote: Sounds like a user-generated FAQ - I think I'll steal that idea too. I'd definitely be interested in seeing that info, as I haven't used anything but SuSE for quite awhile. It would be helpful to me for improving the install process and users wouldn't have to fix the same stuff with every new release. I think, out of a *user* point of view (user is everyone who wants to use Py*, not develop it) binary packages are far more important then source packages. While improving the source setup surly is something important, providing painless binary packages for all major distributions will have (imho) more impact. I pretty much agree, but if something won't build on a particular platform at all, it's kind of hard to do the binary. Ack. I haven't thought about it, when I last uploaded the binary packages to sf. But I guess we have to time it anyway, because the files within /incoming tend to get remove quite often. It does make international collaboration more difficult. See, this is one of the largest problems I currently have (besides my fundamental lack of money) : Where to put files ? It's alway a pita publish something thats larger then 40k. Same here. I don't have a problem mirroring the source tarballs on SF, but I still think there are a lot of good reasons to make riverbank the official site for the base source packages. Phil and I have discussed this in the past and decided against making SF the official home of the source code for various reasons. I think from our perspective (Phil will certainly disagree if the our doesn't apply) it makes a lot of sense to have a home for development, and a separate home for users/binaries/everything else. If nothing else, riverbank is much more convenient on this end and Phil has it highly automated. Personally, I tend to one place to rule them all. Again, simply out of a users point of view. Out of political reasons, I surely understand that you want to host your files there, as it gives you some part of image (i hope you understand what i mean) and serves as advertisement. So there's nothing wrong with it, but I wouldn't duplicate the sources (at least not if riverbanks host is stable enough). What about this solution : Keep the sources on rbc, everything else on (e.g.) sf. And provide transparent links on sf that link to the sources, with a comment maintained at riverbankcomputing. That seems the perfect solution to me. The two concerns are really access and control (along with co-ordination and convenience), and linking is sufficiently transparent to solve the access part without doing any harm to the control part. A lot of projects seem to do something like this. In my mind, the best way to handle this is to keep your RPMs as close as possible to the distribution's RPMs. If RedHat and SuSE package PyQt differently, then our RedHat and SuSE RPMs would be different as well. We'll need a little document telling people what they need to get and how to install it, but they would need that anyway. Distributions won't be able to afford this way much longer - in longterm, It leads to fragmentation and weakens their position. And personally I find it insane, that if Phil or Jim relase a new version, d*v(*k) new packages had to be generated (d=number of distribution, v=number of version, k=number of kdes) - just for this package. Imaging what a waste of resources it is. So if we here could at least minimize d, AS LONG AS we can provide a drop-in replacement, why shouldn't we do so ? If we can't, we have to find another solution, but I really prefer unification. This is open source - we love to duplicate efforts (look at the number of IRC clients on freshmeat, for example). Out of this reasons, I'd like to use a unified .spec, which builds on every platform. I've seen good examples (the one Hans-Peter provided) about using flexible macros which can configure nearly anything. So at least we should give it a try. I don't know enough about rpm to know if this is feasible, but I've wondered if it's possible, and it certainly seems desireable. If someone can make a start on a .spec file that does this and provide me a little support, I'll be happy to try and maintain it for PyKDE. We used to autmatically generate a .spec file (in the Makefile I believe), but I never paid much attention to it. Debian will probably have to go their own way, but hey - Debian always does this ... :) (I've used it exclusivly for over a year) I agree - consistency is nice if you can achieve it, but I don't think it's ever a strong reason for choosing a course if action. I'd trust the package maintainers to use their best judgment and hopefully provide enough documentation to make their releases usable. Well, I do. Consistency == Userfriendly. I think '==' is a little strong, but I'm certainly not opposed
Re: [PyKDE] Screenshots: PyQt/KDE Development-Portal
On 23-Oct-02 Eli Carter wrote: That's a better explanation than I could give. Thanks Jim. :) My pleasure - I liked the QtPy name, too. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Screenshots: PyQt/KDE Development-Portal
On 23-Oct-02 Marc Schmitt wrote: On Mittwoch, 23. Oktober 2002 18:54, Jim Bublitz wrote: My German is virtually non-existent any more, but it would be somewhat of a cross between liebchen and scho/ne Ma/dchen. Scho/n ~= cute - cutie (sounds like 'Q t'), which is sort of a diminutive, like adding -chen on the end of word auf Deutsch (??) It's more like baby talk. Sorry, I can't do umlauts, and my spelling is probably off too. (Babelfish was no help either) Wow. Very good. :) Except liebchen is no german word I know, I'd rather use Schatz (which you call your loved one) or Scha/tzchen (which you *should not* call a (sexual attractive) woman) - I guess there's no direct translation. Now that you mention it, I can't remeber every hearing liebchen at home, but definitely Schatz or Schatzie. Liebchen is the stereotypical Hollywood word used in dialog with German characters - I'm pretty sure it occurs in a scene is Casablanca for example - as in my little liebchen. Now I wonder what the derivation of that word is ... Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] PyKDE and kde 3.0.4
On 22-Oct-02 Jim Gifford wrote: Where can I find a patch for pykde and KDE 3.0.4 libs? At the moment it would require time travel about a week or two into the future. The only problems with PyKDE on KDE 3.0.4 are: 1. There are a couple of bugs in a couple of khtml sip files; see the thread [PyKDE] Runtime issues on SuSE 8.1 on the archive for this list for fixes (these are bugs that gcc 2.95 didn't catch but gcc 3.x does - they aren't strictly required for 3.0.4) 2. Add 304 to the KDEVers list near the top of build.py and KDE_3_0_4 to the %Timeline stmt in PyKDE-3.3.2/sip/kde303/dcop.sip. Also, Marc Schmitt did PyKDE rpms for SuSE 8.1, but I don't know where he's made them available. Marc? It would seem to be trivial to get a new release out, but I have some patches for the latest RH release to incorporate as well, along with a few other minor changes. I just finished overhauling the mail system for my business today (100+ spam/day to 1 spam in the last two days, plus lots of other fixes badly needed - see the spambayes project on sourceforge for a comparable spam filter; I did something slightly different, but theirs is probably better). I also have to file my state use tax returns for the last 3 quarters (I only owe about $50 but it's a PITA to get to). If I don't, I'll be finding out if the county jail has broadband - I'm not that interested in knowing. After that, PyKDE updates are next on the list, and 3.1 should be released pretty soon too. Once again, sorry for the delays. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Runtime issues on SuSE 8.1
On 15-Oct-02 Marc Schmitt wrote: On Dienstag, 15. Oktober 2002 21:37, Jim Bublitz wrote: The string mJ0J0ii should be mJ0J0i. 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 don't know what a 'non-POD type' is, so the error msg isn't very helpful at the moment. Generally, you couldn't have gone that far unless almost everything else was working - this is one of the last few modules in the build. It could also be due to a change in KDE 3.0.4 (I don't have the source to check yet), in which case commenting out the paint method should take care of it temporarily. Also did that, or at least tried to but the error remains. But with this point I'm not quite sure if it was in the right file, as I modified PyKDE-3.3.2/sip/khtmlview.sip, but it complains about khtml_part.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 was looking in the concatenated file and grabbed the wrong paint method, but both have the error. I'll give it another try tomorrow, but this night I have to wait in sorrow. I just recompiled on SuSE8.0/KDE3.0.3 for a Python update and had no errors. I'll pick up KDE 3.0.4 tomorrow and see what's involved in doing the update - probably not much. Then again, since I don't know the real problem for certain, I may not get it fixed that way either :( Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Runtime issues on SuSE 8.1
On 16-Oct-02 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 :) Yeah, I was afraid of that :) (I tend to think the same way) 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 : Thanks for the research and explanations. 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 ? Might be gcc version-related - I'm not sure, but there definitely was an error in my code. I don't think it was an error the compiler would have found though, so maybe something else is going on. Looks like I better set up a box with gcc 3.2 :( That's exactly the reason why I stopped developing C(++) and started python. One of *many* reasons. 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 ... The problems PyKDE had with gcc 2.95-2.96 were (mostly) genuine errors in the code (like promoting private stuff to public unintentionally) that gcc 2.95 let by. There was one problem with 'const' or 'void' (I forget which) that fit your description above pretty well though. ps: I'm just compliling without the paint method. Let's see. I noticed from your followup to this that it worked without the paint method - shouldn't be a problem for most people. The actual calls made to paint are handled on the C++ side (in the libs), so the missing paint method is only a problem if you wanted to subclass and override the method in Python. It wouldn't have worked in earlier versions anyway, so your rpms are no more crippled than previous versions. Just as a plug for the recent build system changes - it would have been a lot more difficult to do a workaround like this with the older build system, and a lot slower too. An 'official' PyKDE/KDE 3.0.4 release will probably wait now until I get a copy of SuSE 8.1 and find a box to put it on (so I can test gcc 3.2) - probably a week to 10 days. I'll probably also switch to sip/PyQt 3.4, but that shouldn't cause any problems for 3.3.2 users as far as I can see. KDE 3.1 isn't too far away either. Persistence in fixing bugs is always appreciated - thanks. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Runtime issues on SuSE 8.1
On 16-Oct-02 Hans-Peter Jansen wrote:
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.0 +0200
+++ ./sip/khtml_part.sip2002-10-16 13:02:32.0 +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,sipClas
s_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?
Thanks!
Sloppy coding on my part - it definitely wants a pointer there.
This goes in the mistakes I made that gcc 2.95 didn't catch
category.
The format string should be:
m - for the KHTMLPart 'this' pointer (equivalent to self in
Python)
J0 - for the QPainter arg
J0 - for the QRect arg
i - for the int arg
or mJ0J0i
The bool* arg isn't passed in under Python; it's the return value
of the paint call instead (yes, sip will let you turn a void method
call into a call that returns a value under Python). In this case,
the contents of the location pointed to by the bool* is modified by
the call to paint, it isn't a parameter that paint uses itself to do
something. That's why the second 'i' in the format string was
incorrect. It's the same thing in both khtmlview.sip and
khtml_part.sip.
In the docs this should read TAKES a QPainter, QRect, int and
RETURNS an int (Python not having a bool type for the return value
prior to 2.2.1)
I probably would have spent a week looking for this silly error
(and it's one I've made before too). Thanks again (both Marc and
Hans-Peter)!
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] kdepyuic broken
On 16-Oct-02 Marc Schmitt wrote: I just tried to use kdepyuic, but it's only chaos. There are missing '', commas where periods expected and lots of function-calls which simply are not there. On the other hand, pyuic does work very well and is able to include kde-widgets which were generated by qtdesigner, but it does not import anything from the kdelibs. Wouldn't it be best to simply include those import statements into pyuic and burn kdepyuic, as this could also reduce confusion about ui-generators ? I'll check it out and either fix it or trash it for the next release. At the moment, I don't recall why I wrote it (I was even surprised to find out I did) - I imagine it came out of a request or comment on the mailing list, as I don't use qtdesigner much myself. It doesn't really do much - I'm surprised it causes that much trouble. I'm not sure what's involved in getting pyuic to add the kdecore/kdeui imports (or more importantly not add them for non-PyKDE stuff). Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] ANN : PyKDE 3.3.2 SuSE 8.1 rpm
On 16-Oct-02 Hans-Peter Jansen wrote:
I hope, I've made the correct fixes to sip/khtml_part.sip:
--- ../PyKDE-3.3.2.orig/sip/khtml_part.sip 2002-08-21
20:08:45.0 +0200
+++ ./sip/khtml_part.sip2002-10-16 21:11:18.0 +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,mJ0J0i,sipThisObj,sipClass_
KHTMLPart,ptr, sipClass_QPainter, p,
+ sipClass_QRect, r, i))
{
Looks correct to me, but I'm the one that screwed it up in the
first place :)
Thanks.
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Runtime issues on SuSE 8.1
On 15-Oct-02 Marc Schmitt wrote: Unfortunatly, I wasn't able to compile PyKDE for KDE3.0.4, the compilation broke while compiling about a missing extraH/kde304 dir. Simply setting a link from the kde303 dir didn't work. Jim, any hints ? I registered the fact that KDE3.0.4 exists a few days ago, but for some reason it never dawned on me that I might need to do something about it ... I'm in the middle of something I need to implement soon (rewriting my mail handling top to bottom), so it will be a few days before I can look at KDE3.0.4 - from the announcement it doesn't appear much needs to be done. Setting a link seems like it *should* work - a quick and dirty solution would simply be to create extraH/kde304 and copy all of the files from extraH/kde303 into it. Those are (mostly) h files which aren't normally found in kde*/include. The correct way would be to copy the same set of files from a KDE3.0.4 kdelibs source distribution to the new directory, EXCEPT for kicontheme.h, pct.h, and pykdekshortcutlist.h, which you'd still want to copy from extraH/kde303. pct.h is a hack to allow '%' type formatting in an sprintf statement under sip, and the other two are (very slightly) modified version of the corresponding kdelibs h files. The other places you'd (probably) need to make changes are: 1. build.py - add 304 to KDEVers list (global, near top of file) 2. PyKDE-3.3.2/sip/kde30/dcop.sip - add KDE_3_0_4 to %Timeline statement From the last couple of KDE releases, I'm guessing not much else really needs to be changed, but don't hold me to that. KDE 3.1 will have lots of changes, so don't expect to be able to build PyKDE (as it is now) against that. Bill Soudan also sent some patches for build.py for RH8.0 (thanks Bill!) which will be in the next release. I also have a hack to allow building PyKDE as a user instead of requiring root privileges (still need to be root to install of course), but I'm not sure if that's worth releasing. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Runtime issues on SuSE 8.1
On 15-Oct-02 Marc Schmitt wrote: On Dienstag, 15. Oktober 2002 18:57, Jim Bublitz wrote: Setting a link seems like it *should* work - a quick and dirty [...] The other places you'd (probably) need to make changes are: 1. build.py - add 304 to KDEVers list (global, near top of file) 2. PyKDE-3.3.2/sip/kde30/dcop.sip - add KDE_3_0_4 to %Timeline statement Ok, I modified the points and it passes the initial setup, but when it tries to compile khtml, the following happens : make[1]: Entering directory `/usr/src/packages/BUILD/PyKDE-3.3.2/khtml' g++ -c -pipe -w -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -DNO_DEBUG -D_REENTRAN T -fPIC -DSIP_MAKE_MODULE_DLL -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -fno-exceptions -I- I -I../extraH -I. -I../../../../../include/python2.2 -I/opt/kde3/include -I-I -I/opt /kde3/include/khtml -I-I -I/opt/kde3/include/dom -I-I -I/opt/kde3/include/kparts -I- I -I/opt/kde3/include/kio -I-I -I../kdecore -I-I -I../kio -I/usr/lib/qt3/include -I/ usr/lib/qt3/mkspecs/default -o khtmlhuge.o khtmlhuge.cpp sip/khtml_part.sip: In function `PyObject* sipDo_KHTMLPart_paint(PyObject*, PyObject *)': sip/khtml_part.sip:128: cannot pass objects of non-POD type `class QRect' through `. ..' make[1]: *** [khtmlhuge.o] Error 1 make[1]: Leaving directory `/usr/src/packages/BUILD/PyKDE-3.3.2/khtml' make: *** [sub-khtml] Error 2 Bad exit status from /var/tmp/rpm-tmp.2774 (%build) Any hints ? I don't know if this is causing the problem, but in khtmlview.sip, line 87 is: if (sipParseArgs(sipArgsParsed, sipArgs, mJ0J0ii, sipThisObj,sipClass_ KHTMLView,ptr, sipClass_QPainter, p, sipClass_QRect, r, i)) The string mJ0J0ii should be mJ0J0i. I'm not sure why this error wasn't caught before. It should cause a runtime error at the very least. If that doesn't fix it (and I don't see why it would), you can try commenting out (//) the paint method and everything between and including %MemberCode -- %End after paint in the same file and see what happens. I don't know what a 'non-POD type' is, so the error msg isn't very helpful at the moment. Generally, you couldn't have gone that far unless almost everything else was working - this is one of the last few modules in the build. It could also be due to a change in KDE 3.0.4 (I don't have the source to check yet), in which case commenting out the paint method should take care of it temporarily. Sorry I can't be of more help. Don't spend a lot more time on it if you can't work around it easily - I should have the update available by the end of the week or early next week. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Problem with German characters
On 15-Oct-02 jblazi wrote:
On Tuesday 15 October 2002 20:57, david wrote:
Then I get the next problem. Here is my code:
string.split(unicode(self.widget.text.eingabe.text()),'\n')
tmp = unicode(self.widget.text.eingabe.text())+'\n'
try:
exec tmp in user_name_space
except:
txt = str(sys.exc_info()[1])
return
Here I get the error message
ASCII encoding error: ordinal not in range(128)
I'm using this :
blah = textedit.text().latin1()
It works fine.
It doe not work for me; I get the same error message as above.
(This seems to be no Python problem, as exec('a=รถ') works.
I'm not at all clear on what your code is trying to do, but if
.text() is Qt code, it almost invariably returns a QString,
therefore you should need latin1(), utf8() or something similar from
QString to return an actual character string before using it with
any Python functions.
Your Python example would work because you're not passing exec a
QString. Maybe try a print tmp before the exec call and see what
string is actually being passed in tmp, or print the result of
*.text() and see what it returns. I don't think you should need
unicode for o-umlaut, but I'm far from being knowledgeable about
this stuff.
Jim
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] Debian packages location
On 04-Oct-02 Frederick Polgardy Jr wrote: Anybody know where the 3.4 family of .debs for SIP/PyQt/PyKDE can be found? Per Ricardo's message on 9/11, I thought there would be a 3.4 deb of python2.2-qt3, but I'm still picking up the 3.3.2 version. And there doesn't seem to be one for KDE3 at all. The 3.3.2 version of PyKDE should work with sip/PyQt 3.4, so there is no 3.4 release of PyKDE. The next release will be for KDE 3.1. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] RH 8.0 ?
If anyone has built sip/PyQt/PyKDE on the new RH 8.0, I'd be interested to hear the results. Also, what gcc version is RH8 using? Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] PyQt/sip directory?
On 26-Sep-02 Bart Verwilst wrote: When i'm trying to install PyKDE, it complains it couldn't find the PyQt/sip directory, so i have to use the sip dir from the pyQT sources.. Can i copy that dir to some location on my system during the install? And if yes, whereto should i copy it? You should be able to use the -v switch on the 'build' command line to specify the location of PyQt/sip build.py should be checking for PyQt/sip over this list of paths: candidates = [../, /usr/local/, /usr/local/src/,\ /usr/src/, /usr/share/sip, /usr/local/share/sip] Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] PyKDE and libkdegames
On 13-Jun-02 Michael Lauer wrote: Sounds very interesting - could you publish these tools, please? I emailed the tarball to you, but got: do_ypcall: clnt_call: RPC: Unable to receive; errno = Connection refused 220 mars.tm.informatik.uni-frankfurt.de ESMTP. My ISP is continuing to attempt delivery. It appears to be about 90KB - if that's a problem, I can probably post it on sourceforge for ftp. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] PyKDE and libkdegames
On 13-Jun-02 Michael Lauer wrote: Am Mon, 2002-06-10 um 18.53 schrieb Jim Bublitz: I have some semi-automated tools to do it, but they only generate about 80% - 90% clean code and require a lot of manual touch-up. Sounds very interesting - could you publish these tools, please? The short answer has always been I'd rather not - mostly out of embarassment (it's a terrible hack). I'd considered at one time setting this up as a separate project but it really requires other contributors. The negatives of this software are: - it requires PyKDE to run (it's in Python), and therefore Linux - while it naturally reads and writes files, internally the lexer/parser take their input and write their output to KEdit widgets (makes it somewhat IDE-like, can edit files on the fly and even search/search and replace) - the parser is handwritten and very convoluted - even worse is the code that merges a newly parsed h file with a previous version of the same sip file (does versioning) - it's buggy (doesn't handle enums in namespaces correctly, doesn't version enums correctly, sometimes doesn't version anything correctly, sometimes fails to match identical methods across versions) - doesn't create sip-in files correctly (might get close though) - requires manual input (mostly point and click though) As I haven't run it in a month or so, there are probably more problems I'm forgetting, however it takes a lot less time to fix the output from this program than to generate sip files manually. That said, it does most of what's needed to create a basic sip file. Most importantly, it strips variable names and adjusts names for objects in namespaces correctly which is extremely time consuming for things like kparts and kjs, and it does versioning of sip files, given an existing sip file and new h file. It isn't (AFAIK) Qt or KDE specific as far as actually generating sip files. What it needs: - it would probably work better with an actual tokenizer and parser (there are a number available in Python). It only needs a grammar for h files (and sip files, which is more or less a subset), not all of C++. Unfortunately I'm not knowledgeable in this area at all. - it would be desireable to have it generate everything, including configure and make files (some of that gets done, but not enough) - bug fixes, of course - documentation - it could be extended to generate some basic %MemberCode from user input. - it could be adapted to Windows (KEdit-QMultiLineEdit). I probably used a lot of KDE widgets (KTabCtl, KLED, KListBox, KDialog, etc), but that wouldn't be too hard to change. The logic and GUI are mostly separate. I don't have a Windows based computer anymore. In general, this is your basic I needed something simple so I threw it together in a couple of days and then kept adding more features hack. Originally I just wanted to strip variable names automatically. After all that, if anyone still wants to play with it, let me know and I'll write up some simple instructions and mail it off to you. If after looking at it, some one wants to set up a project and go with it, I'm all in favor of it. The entire thing (py/pyc and some unnecessary files) is about 350K untarred, so a basic tarball should be easily mailable. It'll take me a few days to write some usage instructions and do a tarball. The license will be GPL unless someone convinces me otherwise. At the moment I simply don't have the time to work on this or co-ordinate a project, but I'll be happy to answer any questions. If anyone is interested, let me know. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] PyKDE and libkdegames
On 10-Jun-02 Bjorn Pettersen wrote:
From: Jim Bublitz [EMAIL PROTECTED]
Basically, there are only a few simple rules for generating sip
description files (.sip) from C++ headers:
0a. Delete all methods you don't want to expose to Python
(although point 5 below still holds).
Very good point. In PyKDE the goal is to expose everything to
Python, but in cases where you just want Python access to parts of
an API, you can save a lot of work by hiding things. Another
example is that in writing an intermediate C++ wrapper and then
writing the bindings to that instead of the base package, you can
expose very little in the h files that are used in binding and
expose nearly everything (to gcc) in the .cpp files of your
wrapper or in h files that aren't visible in the bindings. In the
extreme you can make the bindings' h files and sip files almost
identical.
0b. Delete all operator overloads (you'll have to write
%MemberCode to access those).
Yep -- not done in PyKDE.
1. Delete any forward declarations
2. Change 'class someClass : public QWidget' to
'class someClass : QWidget'
But only if you have given a definition for QWidget in one of your
sip files, i.e. there is no need to expose the inheritance
relationship if it doesn't buy you anything.
This can be useful if you're inheriting from a templatized class.
Another very good point - I hadn't tried that explicitly, but it
could prove very useful (in fact there's a couple of places in
PyKDE where that might work).
A simple example is in kcharsets.sip
kcharsets.sip has %MemberCode examples with lists and static methods
as well as returning an int argument in a tuple - those cover the
majority of cases. intvaluelist.sip is probably a good example of
%MappedType usage (and then grep the PyKDE sip files to see how the
IntValueList type is used to replace a template type).
7. Anything template based (eg QList QString) will require
either handwritten code or a %MappedType.
A simple example is in the PyQt distribution in qpair.sip. Note
that specific instantiations of a templatized class work fine as
long as SIP doesn't see the template, e.g:
ivec.h:
#include vector
typedef std::vectorint IntVector;
ivec.sip:
class IntVector {
%HeaderCode
#include ivec.h
%End
public:
void push_back(int);
int size();
};
It's sometimes helpful to keep in mind that sip doesn't look in the
h files at all - it only reads .sip files. You can also augment the
h files with code in the %HeaderCode block in the sip file (there
was an example below but I already snipped it).
8. Eliminate duplicate typedefs if any
9. Namespaces need some special handling, mostly in naming
objects in namespaces - see KParts stuff
I.e. if subclassing from a class in the same namespace you need to
prefix with the namespace, e.g:
namespace foo {
class A {...};
class B : foo::A {...};
};
'A' and 'B' will need the namespace prefix nearly everywhere, even
within the namespace itself:
B.h:
namespace foo
{
class B
{
public:
B ();
B (B);
B* self () { return this; }
};
};
B.sip:
namespace foo
{
class B
{
%HeaderCode
#include B.h
%End
public:
B ();
B (foo::B);
foo::B* self ();
};
};
I also forgot to mention that any inline code is stripped out too.
Lastly, you can insert SGML docs in the sip files and sip will
produce a concatenated .sgml documentation file with the proper
switches (see either PyQt or PyKDE - kde.sip or kde.sip-in drive
the documentation construction, but the doc text is distributed
over all of the sip files)
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] Trying to build PyKDE for KDE 3
On 13-Jun-02 Alex Willmer wrote:
Thankyou for the tip, I tried this out and the 'make install' run
got a bit further, unfortunately another import error occurred.
Judicious (although very possibly not correct) repetition of
the above with the '%Include netwm.sip' line, got a little
further, but after that the import error gets a bit close to
the bone.
I've had a look at the libtool line in question, it does contain
the correct library ('-L/opt/kde3/lib'), however it is a relink
command, which libtool warns of in the preceding line:
libtool: install: warning: relinking `libkdecorecmodule.la'
Yes - that's normal.
I'm afraid libtool and type_info functions are currently beyond
me.
As I posted earlier, I'm still not very enlightened regarding
type_info, but it doesn't appear to be the problem.
Thanks for taking the time out to help me with this.
We try to give everyone their money's worth, and unfortunately
sometimes that's what you get :)
As an aside. Just some further background, in case of rpm
screwiness, possibly due to a switch from some unofficial
texstar kde 3.0.1ish/cvs rpms, to the official Mandrake ones
while trying to build PyKDE previously (of course rerunning
configure afterwards) I nuked the build directory and started
afresh from the 3.2.4 tarball today. It appears that the
Mandrake RPMS currently available for 3.0.0 report as 3.0.1 in
the headers with kdeverison.h containing:
#define KDE_VERSION 301
#define KDE_VERSION_STRING 3.0.1 (CVS = 20020327)
Those are the Red Hat rpms, which is what I'd expect for Mandrake.
They definitely are the 3.0.0 version, just mislabeled.
I've modified ckversion.py accordingly. To the best of my
knowledge, these are definitely the 3.0.0 rpms, 'rpm -qf
/opt/kde3/include/kdeversion.h' reports'kdelibs3-devel-3.0-10mdk',
as found at:
So either I've screwed up so well I can't even spot the error, or
there is something else going on.
At this point I think there definitely is something else going on.
I've had the RH install (after the version fix) verified, and
another poster verified a Mandrake 8.2 install. The sequence of
errors you're getting doesn't point to any particular code problems
and looks more like a library version problem with something (but
not the 3.0.1 stuff). You'd get these kinds of problems if, for
example, you were linked to Qt1.4.2 instead of Qt3.0.4 (having done
it myself).
I looked at the log file (thanks for posting it!), and don't see a
problem. I'd suggest the following:
1. If you had sip/PyQt installed from Mandrake, get rid of them
(rpm -e). I'm not sure which version they are - if they're pre-3.1,
they have libsip in the wrong place (it should only exist in
python/site-packages now - remove any other versions in /usr/lib,
/usr/local/lib or where-ever). If that was the case, then download
sip and PyQt 3.2.4 from riverbankcomputing.co.uk and
rebuild/re-install. It might also be a good idea to clean all of
the sip/PyQt/PyKDE stuff out of python/site-packages too - maybe
look at libkdecore.la *first* (it's a text file) and see if there's
anything unusual in there (wrong path to libs, etc) sip, PyQt and
PyKDE all need to be 3.2.4 for KDE3.0.0.
2. If the first step doesn't appear to be the problem, you might
want to make sure you have a clean KDE install - check for KDE libs
(other than symlinks) in /usr/lib and other locations other than
/opt/kde3/lib. Also check for libqt and libqt-mt and look for
multiple versions of those (for example libqt.so.2 and libqt.so.3).
If you can, delete and re-install KDE (that's pretty messy on SuSE
because their installer 'yast' depends on KDE - don't know about
Mandrake). Will the PyQt examples run?
Again, the libkdecore.la file in site-packages might provide a hint.
If a necessary lib (like libkdecore or libqt) turns up earlier in
the search path than /opt/kde3/lib or /usr/lib/qt3, it'll get used
instead - I've tried to order things to prevent that, but might not
have eliminated all of the possibilities.
3. Try a clean build of PyKDE - running './configure' again deletes
everything and rebuilds from the ground up. I know it's a long
compile - the next version will be faster, so you might want to wait
for that. I don't think anything will change in the next version
that will affect the problem you're having though. Restore all the
stuff you commented out too (starting with kmutlipledrag.sip) - it
should all work once the real problem is fixed.
I've run into these kinds of problems on my own systems and they
can be very frustrating. The fix is usually simple once you find
the cause. I always appreciate it when people stick with it this
far and am happy to provide any help I can. Personally I think it's
worth it - I've been writing stuff for my own use with PyKDE the
last few weeks and it's really been fun and productive too.
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] Trying to build PyKDE for KDE 3
On 10-Jun-02 Alex Willmer wrote: Hello All I'm trying to get pykde 3.2.4 working with kde 3.0.0, however make install fails with the error below. I'm not sure where to look to find the solution, make appeared to work without errors. The configure line I used was: ./configure --with-qt-dir=/usr/lib/qt3/ --with-pyqt-sip-dir=../pyqt-3.2.4/sip/ --with-kde-dir=/opt/kde3/ configure should find all of those locations, except perhaps not the lower case PyQt. Looks fine. The system is Mandrake 8.2 with the mandrake rpms of kde 3.0.0, sip pyqt 3.2.4 were built from source. I've deleted the DocStruct class lines and added the newlines to pct.h in extraH/kde300/. Sloppy work on my part - those should've been fixed already. Please if anyone can point me in the right direction, I would love to get this working. Last lines reported by make install are included below. I'll also post config.log to: import libkdecorec ImportError: /usr/lib/python2.2/site-packages/libkdecorecmodule.so: undefined symbol: __ti13KMultipleDrag This indicates libkdecore.so (in /opt/kde3/lib) has an undefined symbol __ti13KMultipleDrag. If you do: nm /opt/kde3/lib/libkdecore.so | less and then /__ti13KMultipleDrag to search for the symbol (you can grep instead of 'less' too), it either shouldn't be there or will have a 'U' next to it. If it's there and has an address, something else is wrong. According to the same 'nm' line with a -C switch to unmangle the names, the corresponding item on my system is defined as a 'type_info function'. I don't know what that is for sure or how it gets there, so I'm a little at a loss as to how to fix this. Do other Mandrake 8.2 users have this problem? On SuSE (and I assume RH and Debian) this symbol is defined and the install/link step works fine. The only fix I can think of at the moment is to go to: PyKDE-3.2.4/sip/kde30/kdecore.sip-in and comment out (//) the line %Include kmultipledrag.sip I don't believe anything else references this class. After that do: build -mkdecore and recompile (make - only kdecore should recompile, saving you about an hour). You shouldn't need to run configure again. These kinds of install failures come about because of things missing in the KDE libs - I have no idea how that happens, but there are a number of things in the .h files that don't make it to the libraries. You won't have the KMultipleDrag class with this fix. My only concern in this case is that the 'type_info' functions (whatever they are) are missing as a group, and there are a number of them. I can't verify any of this because I don't have a Mandrake system, and it works on my systems, so please let me know what happens. I'll look into this some more and see if I can figure out what a 'type_info function' is. You might also want to check the libtool command line just before the install failure and make sure it has a '-L/opt/kde3/lib' and not some other KDE location (like kde2 if that's also on your system) - KMultipleDrag is new in 3.0.0. If that does occur, you can try adding a '--with-kde-libraries=/opt/kde3/lib' to ./configure (your log looked correct however, so I wouldn't try that unless there's a clear indication that it's a problem; re-running configure will require a complete re-compile). Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] PyKDE Bug
In KLineEditDlg in PyKDE the static method 'getText' does not work correctly - it generates a runtime error under some circumstances. I'm not sure of the exact problem, but it's in handwritten code for this method (which should return a tuple of QString and int). This applies to all PyKDE/KDE versions. The workaround is to instantiate KLineEditDlg, run it with exec_loop, retrieve the button pressed from exec_loop's return value, and retrieve the text entered using the KLineEditDlg 'text' method. The tuple 'getText' returns contains both values, and 'getText' does the exec automatically, with no need to instantiate KLineEditDlg (or would if it worked). This will be fixed in the next PyKDE release. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
RE: [PyKDE] Deleting items from Canvas
On 01-Jan-70 Moray Taylor wrote: I have a program that puts items onto a canvas, keeps a reference to it, and deletes the reference when I want to remove the item from the canvas. What I want to know is... A) Is this all I need to do? B) If not, what is the reccommended way of removing items from a canvas? The reason I ask, is that I run PyQT on SGI, Intel, and PowerPC, the results from the PowerPC version are very different to the Intel/SGI, I cannot get the items to remove themselves from the canvas on PPC, the code I use is *exactly* the same. I'd assume in that case you don't have any stray references to the Python object hanging around which can cause problems. I need to know if it's the PowerPC with the problem or otherwise. When I've had problems using 'removeChild' on x86, I've used something like: def removeWidget (self, w) #w is a QWidget/QObject descendant dummy = QWidget () w.reparent (dummy, QPoint (0, 0)) # when dummy goes out of scope, it gets garbage collected # along with all of it's children (and the corresponding # C++ objects get destroyed as well) The way Qt handles the above is different than the way 'removeChild' followed by 'del w' would work. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] PyKDE with KDE 3.0.1?
On 03-Jun-02 John J. Lee [EMAIL PROTECTED] wrote:
I tried building PyKDE 3.2.4 against KDE 3.0.1, and it refuses to
build.
I realise Jim hasn't updated it yet for this KDE version, but is
this really necessary -- isn't it possible to just give a warning
during configure, and go ahead and build anyway? I presume
3.0.1 isn't monumentally different from 3.0.0, so that most /
all of it should build, even if the wrapper is missing some new
features?
Actually I didn't think PyKDE would build with 3.0.1 after looking
at diffs of the h files (and in fact I'm not sure it does quite -
see below). It's impossible to predict what will change - usually
if only the last digit of the version increments, the changes are
small. However, the changes from 3.0beta2 to 3.0.0 were major.
You can always modify 'configure' and scripts - it's not hard to
find the version check. As a policy for a release, I don't think
it's a good idea - the check is done (among other reasons) to
prevent people from building a PyKDE that doesn't work.
Niggle: The `build' script has /usr/bin/python in the #! line.
#!/usr/bin/env python
is more standard, since as I'm sure you (Jim) know, it will find
Python wherever it may be hiding.
This was intentional (it's called from configure using
'$PYTHONINTERP build options', and configure knows where Python is
located), but it's incorrect for 'build', since it needs to be able
to run stand-alone. I'll fix it for the next release. Thanks.
(Can't remember why I thought that was better at the moment - arg
passing?)
On 03-Jun-02 Ricardo Javier Cardenes Medina [EMAIL PROTECTED]
wrote:
Modify function 'checkOptions' to recognize KDE 3.0.1. Search
for:
elif (pair [0] == '--kde') or (pair [0] == '-k'):
kdeVersion = unversion ('KDE', pair [1])
if not kdeVersion in KDEVers:
and then change it to:
elif (pair [0] == '--kde') or (pair [0] == '-k'):
if kdeVersion == 301:
kdeVersion == 300
kdeVersion = unversion ('KDE', pair [1])
if not kdeVersion in KDEVers:
That worked for me and I haven't had problems since then. Of
course, YMMV.
From the h file diffs between versions I didn't think it would
build. The main reason I thought that is that some methods have
changed from 'void foo' to 'virtual void foo'. That's hardcoded
into the *.sip files, so rebuilding with 3.0.1 won't catch that
change. Apparently gcc and ld don't notice this change, but the
resulting code isn't strictly correct and may cause problems.
As with a lot of stuff in PyKDE, this may occur in methods hardly
anyone will use, so I wouldn't say Don't do this!. In fact I'm
very pleased with the fact that the new build procedure is as
hackable as it is. But it may not work in all cases.
Jim
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.gmd.de/mailman/listinfo/pykde
Re: [PyKDE] PyKDE with KDE 3.0.1?
On 03-Jun-02 Bret McMillan wrote:
On Mon, 3 Jun 2002, Jim Bublitz wrote:
More data:
[bretm@zealot kde]$ hostname
zealot.devel.redhat.com
[bretm@zealot kde]$ pwd
/usr/include/kde
[bretm@zealot kde]$ grep -r KDE_VERSION .
./kdeversion.h:#ifndef _KDE_VERSION_H_
./kdeversion.h:#define _KDE_VERSION_H_
./kdeversion.h:#define KDE_VERSION 301
./kdeversion.h:#define KDE_VERSION_STRING 3.0.0-10
./kdeversion.h:#define KDE_VERSION_MAJOR 3
./kdeversion.h:#define KDE_VERSION_MINOR 0
./kdeversion.h:#define KDE_VERSION_RELEASE 1
./kdeversion.h:#endif // _KDE_VERSION_H_
./kprotocolmanager.h:QString(Mozilla/5.0 (Konqueror/%1;
compatible MSIE
5.5; X11)).arg(KDE_VERSION_STRING)
[bretm@zealot kde]$
Thanks! I'm assuming from KDE_VERSION_STRING and the RH7.3 release
date that it's still 3.0.0, despite the '301'.
Of course the other possible fix is to modify kdeversion.h (even
temporarily - just while running configure). Presently configure
only looks at the KDE_VERSION line - just change '301' to '300'.
3. Enabling Python-based plugins and panel applets for KDE (not
necessarily PyKDE related - separate project/still sip-based).
Hmmm. Got any info along these lines? If this is done cleanly,
I'd consider using PyKDE for my panel applet instead... :)
I'm not sure this applies perfectly to panel applets, but here's
how I did it for KSpread: You basically need two C++ libraries. The
first is a general library which wraps the Python interpreter and
provides some hooks for loading/running scripts and returning
results. That lib should support any kind of Python-based plugins,
applets or KParts. (Basically KDE-specific embedded Python)
The second lib is specific to the app you're plugging into, so each
app needs it's own wrapper (not full bindings though). That lib
knows the API of the parent app (for example, KSpread, noatun,
panel applets) and also knows how to load the first (interpreter)
lib and talk to it. You also need an app specific .rc file for the
plugin lib.
The KDE app finds the .rc file in it's
share/apps/appname/kpartsplugin subdirectory and uses that to
load the app-specific lib. The app-specific lib loads the the
interpreter lib. In the case of KSpread, the .rc file/lib also
includes some menu additions to allow you to load an arbitrary
Python script via the plugin. The script imports bindings for the
parent app's wrapper (say 'import pyKSpread') - the bindings are
just a simple wrapper:
In C++:
void Wrapper::setCell (char *cellAddr, char *value)
{
someKSpreadClassInstance-setCell (row (cellAdrr), col (cellAddr),
value);
}
In sip:
class Wrapper
{
setCell (char *, char *);
};
In Python:
from pyKSpread import Wrapper
pi = str (3.1416)
w = Wrapper ()
w.setCell (A3, pi)
That's really what most of the wrapper consists of on the
C++/sip side. To get KSpread to run arbitrary Python scripts or load
Python-based built-in spreadsheet formulas adds about 1MB of
overhead - 800KB+ of which is the Python interpreter. With the
little testing I did, Python based formulas were within +/- 10% of
the compiled in formulas - close enough in speed that they might
have even been slightly faster (KSpread overall is horribly slow
compared to StarOffice). Like any plugin, this actually calls into
the KSpread C++ code to do it's work - the Python script just makes
those calls. It's all pretty high level.
In addition, the simple C++ wrapper allows you modify the exposed
API - for example, the KSpread API only takes (int row, int col)
for cell addresses, so I wrote a little extra code to handle cell
addresses like (A3) or (A1:H3), etc. as well as regrouping the
classes/methods in a more manageable fashion for scripting (an
architecture that makes sense for a standalone app isn't
necessarily the best way to script it). When done this should be
pretty newbie friendly, unlike PyKDE/PyQt.
So you basically have: C++ interpreter lib, C++ interface/wrapper
lib, XML rc file and wrapper/binding (another lib via sip).
The code to do all this took about 4-5 hours (really easy). It
probably took another 20 hours to figure out the KSpread API, and
about 40 hours or more (not kidding) to get the configure/make stuff
working. Of course it still needs a lot of cleanup, testing and
especially docs. The only other thing I plan to add is simplified
dialog construction, since the rest of the GUI is already in
KSpread. Don't need PyKDE at all for this (although it could be
imported, just like any other Python lib).
Anyway, I have all this stuff put together, but the makefiles are
pretty machine specific and nothing's too organized. I'm not sure
if it even works at the moment. If you want to take a stab at it, I
can send you stuff, but it's really a mess right now. It's also
still at KOffice 1.1, but that doesn't matter for panel applets. As
far as the wrapper and bindings - they're really easy and I can give
you a few general rules for creating the wrapper and the sip files
for the bindings
[PyKDE] KDE 3.0.1
Just when I thought I was finished for a while, KDE 3.0.1 is released. I haven't downloaded it yet, but from the ChangeLogs, it looks like there's probably enough new stuff to warrant a PyKDE update. 'cpp' file changes make no difference, h file changes are what matter, and it looks like kio and some others have some new methods. The coming weekend is a holiday in the US, and I'm in the middle of some other stuff, so it will be at least several weeks for an update. The other stuff I'm in the middle of is business forms (invoices and stuff). I've been using ReportLab (http://www.reportlab.com) and it's a great piece of software. It allows you to compose pdf files in Python, which wasn't the first thing I had in mind but turns out to be a great solution both for printing, previewing and emailing this kind of stuff. I was able to write a single Form class that will handle all of the various docs (more than half a dozen) I need to generate in about a day and a half. Next I have to do the UI in PyKDE - I hope that's as easy to use :) The other piece of news is that Ricardo Cardenes is modifying the PyKDE 'build' script to enable concatenating all of a module's cpp files into a single huge file. He's doing it for Debian, but is contributing the changes back to PyKDE, and this will be an option in a future version. No news yet on how much compile time is affected. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] Re: PyKDE-3.2.4-1 build problem on MDK 8.2
On 22-May-02 Antti Markus [EMAIL PROTECTED] wrote: When I'm trying to build PyKDE-3.2.4-1 then /configure --with-qt-dir=/usr/lib/qt3 --with-kde-dir=/opt/kde3 fails as follows: [snip] checking options Building dcop kdecore kdesu kdefx kdeui kio kfile kparts khtml kjs kspell kdeprint sip: dcop sip: sip/dcop.sip:44: parse error sip -t Qt_3_0_4 -t KDE_3_0_0 -t WS_X11 -I sip -I ../PyQt-3.2.4/sip/ -c dcop -m dcop/Makefile.tmp sip/dcop.sip -- failed I'm running Mandrake 8.2 with KDE 3.0.0 and Qt 3.0.4. PyQt-3.2.4 compiled and installed fine and is working OK. What might be the problem? I have also attached copy of config.log as conf.log.gz. The config log didn't make it to the list, but my guess is that you're not running a current version of sip. Try 'sip -V' - it should return at least 3.2, preferably 3.2.4. If that isn't the problem, please let me know. If the sip version is 3.2, you can delete line 44 and the preceding comments BUT, you need to do the edit on PyKDE-3.2.4/sip/kde30/dcop.sip-in, which is the base file used to create dcop.sip (otherwise your edit will get overwritten). Line 44 is a %Feature definition for sip which is no longer used and doesn't need to be there. With that line deleted, PyKDE might even build with an older version of sip, but it won't run correctly. If you do need to upgrade your sip version, it would be best to remove the older sip version (and PyQt, which would also need to be rebuilt) first. Please post again if the problem persists. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] PyKDE Bug Report
In PyKDE-3.2.4/sip/kstdaction.sip, the 'print' method/function needs to be modified in two places to look like the following: static KAction* print (SIP_RXOBJ_CON, SIP_SLOT_CON(), QObject*/Transfer/ = 0, const char* = 0)/PyName=printAction/; KAction* print(SIP_RXOBJ_CON, SIP_SLOT_CON(), KActionCollection*, const char* = 0)/PyName=printAction/; (the lines are not wrapped in the actual file) The change is the addition of /PyName=printAction/ to each declaration. This directive changes the name used to call the method/function in Python. 'print' cannot be used as the name of a method or function, since it is a Python reserved word. 'print' is not usable in the current release because of this name clash. The new method/function name will be 'printAction' (actually 'KStdAction.printAction(...) in both cases) for Python usage. After editing kstdaction.sip, you can rebuild only the kdeui module with (current directory == PyKDE-3.2.4): build -m kdeui or you can run ./configure to rebuild all modules. Run make and make install to finish the upgrade. The release file will be modified and posted in the next several days. The new release file name will be PyKDE-3.2.4-1. The version number will remain 3.2.4. The release file also contains modified docs reflecting the name change. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] PyKDE Release
The first bug in the new release turns out to be in the README file. I believe I already posted this info to the list, but I'll repeat it (and update the README) The release is now available on http://riverbankcomputing.co.uk sip/PyQt currently link to qt-mt if you have it. KDE3 is usually built with qt-mt, so there is no problem there. KDE2 however is built with qt. If you have KDE2 and Qt = 2.3.1, you will have both qt and qt-mt libs. In that case, PyKDE configure should fail if you built sip/PyQt normally (PyKDE checks for a qt/qt-mt mismatch). The workaround is to hide libqt-mt.* (rename them for instance) when building sip/PyQt/PyKDE. You can restore libqt-mt.* after building. I forgot to include this info in the README. That of course means you can't use Qt threads and PyKDE (for KDE2.x only) at the same time. Also, it appears that PyKDE now builds successfully with gcc2.96, which affects RH and Mandrake 8.2 users. Let me know if that isn't correct. Thanks to Bill Soudan for RH testing and info. Now I can return to deleting Korean spam and Klez-infested emails. (Out of 185 emails this morning, all but 30 were spam or virus-generated. Arghhh!). Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
[PyKDE] ANN: PyKDE-3.2.4
The next PyKDE release is *almost* ready. I'm doing a last compile overnight and will ship it off to Phil sometime tomorrow or Friday. Given the difference in time zones and other unforeseeable stuff, I expect it will be available sometime this weekend or shortly after. I've asked Phil to post to the list when the download is available. The release will be PyKDE-3.2.4. (no '2' and no 'beta') While there aren't any major changes for KDE versions 3.0.0, I'd still recommend upgrading for the changes/enhancements to sip since sip 3.0. This version requires at least sip/PyQt 3.2 and has been most thoroughly tested against 3.2.4pre1, with the final 3.2.4 expected shortly. This version supports KDE 2.1.1 through KDE 3.0.0. Support for KDE 3.0beta2 has been dropped. The two other major changes in this release are in the build process and the docs. There is now only a single tarball (about 750K) that builds for any supported Qt/KDE/Python combination. The file size has been reduced from 3.5MB+ because you no longer get the C++ files in the tarball. The tail end of ./configure will run the 'build' script which will use sip to build the C++ files (and edit the Makefiles) for the versions of Qt/KDE/PyQt that configure detects on your system. From the users standpoint, the entire process is just the familiar './configure;make;make install'. The build process does not require you to have automake/autoconf, and in fact you'd have some trouble getting those to work with the new build system. I've been running this system for several weeks (I do a lot of compiles on three different systems) and it's run very smoothly for me. I expect some problems so PLEASE post here with any problems you encounter (or fixes you work out) and I'll try to get you running as quickly as possible. One of the other advantages (hopefully) of the new system is that small patches should be easy. Please read the README file for more info and complete install instructions. There are also new '--with' switches for configure that will hopefully solve most problems. The docs are pre-built and reside in the 'doc' directory in html and sgml. There is now a table of contents and the html file names are somewhat meaningful. There is only one set of docs for all versions. I've gone over the docs fairly carefully, but it requires reviewing a few hundred files. Please report any bugs/errors/omissions in the docs, however small. The Makefiles still include targets like 'install-doc', but it's unlikely that they'll do anything useful. This is pretty much the final form I expect PyKDE to have - I'm sure bug fixes will be required and the Makefiles still need some cleanup, but I'm not planning any new features or modules. The next release (other than fixes) will occur either when sip changes significantly or a major KDE release happens. I expect to maintain PyKDE (for all supported KDE versions) for the forseeable future. I'm always open to suggestions. Jim ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
