WANTED: Python binding

[amp]

I would really like to have a python binding for CWiid. I would allow for easy experimentation with input processing algorithms. (Also I plan on creating a uinput python binding so I could use it for advanced interaction)

I have a fair amount of experience with SWIG (www.swig.org), so I am going to start creating a binding using that. I will post a patch as soon as there is any useful code.

If anyone has other opinions as to how this should be done please tell me. I just like SWIG because it is quick and easy. Also if I am careful when creating the binding it will be easy to use the same SWIG file to create Java/C#/etc. binding if anyone wants to.

I will be working with the SVN trunk.

-Arthur

[Game_Ender]

How heavy is your API? If its a simple C one then swig with some custom python code on top to make a little more OO would probably due nicely. If you were just doing Python I would highly recomend  Py++ because its a more powerful wrapping tool for python than SWIG. Yet if you intend to support multiple languages SWIG might be best.

[dsmith]

I like SWIG for the following reasons:

1. Every time the subject comes up, people stop me in mid-sentence with a single word: SWIG. You just can't beat the support and longevity that comes with that kind of user base.
2. With Py++, it looks like we'll need to wrap CWiid in C++. The API works in C++ as is (with the extern "C" block), but I don't want to have to directly support it. Sounds like this would also cause problems when calling Python from C, which we need to support python plugins. Correct me if I'm wrong on this point.
3. Multiple language bindings for free.
4. Another horrible pun: CWIIG

I'm not attached to it, though - what does Py++ offer that SWIG doesn't?

The API isn't too heavy, in my opinion - ~15 functions. It's currently in flux - see branches/api_overhaul and 19 for an idea of what it will look like.

[dsmith]

Anyone working on this? I'll be focusing on Python as soon as I finish the libcwiid rewrite. If anyone has any work on this front, we need to get it checked in.

[amp]

I have just tested the code in branches/cwiidpy/ and it works very well.

I did discover that although Wiimote.set_mesg_callback is provided it doesn't work because the function has the calling conventions to work as an accessor (setter). I have attached a patch to remove the broken method leaving the setter only.

It seems that it may be time to roll this into trunk.

[amp]

Remove broken method

[dsmith]

Good call.

I'm in the process of rolling it into trunk, just gotta integrate it with wminput and the build system.