[kde-edu]: [Marble-devel] Python bindings for the Marble widget and friends

[Simon Edwards]

Cross posting to kde-edu. Module overlords / maintainers, do you want to 
comment on the first part of this email about having the marble python 
bindings in kdeedu?

Hello,

Torsten Rahn wrote:
> On Thursday 16 October 2008 16:19:17 Simon Edwards wrote:
>> The soft feature freeze is almost here but there is one thing that I've
>> wanted to have for a while now and which I want to get in for KDE 4.2.
>> Python bindings for the marble widget so that I can use it from my
>> Python code.
> 
> Wow, that's incredible great news :-)

:)

 >> I've got the bindings mostly done, and I would like to check they in
 >> directly to kdeedu (in a marble/src/bindings/python directory).

 >> This
 >> would introduce a an optional Python (PyKDE4/kdebindings module)
 >> dependency for marble and the kdeedu module. Has anyone got any
 >> comments, advice or even objections to the python support being kept in
 >> with kdeedu?
 > What size do the sources have?

Comparable in size to the header files in your public API. Not huge really.

 > I'm all for it (as I consider it convenient if
 > the bindings stay in the same module). But of course you'd need to ask
 > Anne-Marie and probably also Allen Winter.

The binding code itself is not very big in size and I find it convenient 
and logical that it be kept in kdeedu too. It savings having to split 
off a new kde module, e.g. kdeedu-bindings. Also by having the bindings 
in kdeedu, it is easier to have software which uses them in kdeedu too.

>> I've got the bindings mostly done, and I would like to check they in
>> directly to kdeedu (in a marble/src/bindings/python directory). 
> Would be fine with me. Is there anything for us to do to make sure that you get 
> aware of any future API changes? 

I use a program called 'twine' which takes .h files and turns them into 
.sip files. .sip files are basically .h files with extra binding stuff 
added (+ manual fixes where needed). These files are used to generate 
the real bindings code which is compiled and installed into your python 
site-packages directory. Twine has some support for doing updates from 
changed .h files. The work method that I have for the rest of the python 
bindings (which covers almost all of the big KDE libs) is to do nothing 
for most of the development cycle and then quite late in the process 
once the libraries are frozen up I jump into action and madly update the 
bindings and hope that no-one changes any APIs before real release. ;-) 
Actually during the RCs phase I watch the APIs like a hawk.

The best thing that you can do for me is to sort out the class exports 
and only install the headers which are needed by the public API. It just 
makes it clearer for me which classes should be wrapped and which ones 
can be ignored.

>> Some technical comments. The ClipPainter class needs to be exported
>> otherwise I can't bind to it or the GeoPainter class. 
> Be aware that ClipPainter is not meant to be part of the public API (that's 
> what GeoPainter is for).

I guess ClipPainter could be exported and marked as @internal in the docs.
>> Also some methods in classes specify
>> methods without implementations. Are you people interested in more
>> details about where the headers could be improved? 
> 
> Yes, very much so. We're always interested in suggestions and details :-)

I'll post a list of 'anomalies' after I've checked in the code.

cheers,

-- 
Simon Edwards             | KDE-NL, Guidance tools, Guarddog Firewall
simon at simonzone.com       | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."