Re: [PyKDE] PyKDE and libkdegames
Am Don, 2002-06-13 um 20.47 schrieb Ricardo Javier Cardenes Medina: On Thu, Jun 13, 2002 at 09:46:26AM -0700, Jim Bublitz wrote: 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. I'd like to see that :-) Me, too! :) ___ 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
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? Yours, :M: ___ 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 Thu, Jun 13, 2002 at 09:46:26AM -0700, Jim Bublitz wrote: 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. I'd like to see that :-) ___ 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
[PyKDE] PyKDE and libkdegames
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Could anyone give me any advice on how to make a wrapper for libkdegames (or any of the other extra libs for that matter) in the way PyKDE wraps kdelibs? My first obvious steps would be to look on a cvs or the sip docs, but lacking both I hope for some help here. :-) - -- Neil Stevens - [EMAIL PROTECTED] I always cheer up immensely if an attack is particularly wounding because I think, well, if they attack one personally, it means they have not a single political argument left. - Margaret Thatcher -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9BFzaf7mnligQOmERAjQ7AJ92NteQZbbAR/x15Kma3/Y9YXKa2ACfS/Mq 7jmeFlmdCZkW/3ebgTChJKc= =NBc+ -END PGP SIGNATURE- ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
