Hello,
I am Matthias, 23, from Germany and I am interested in participating in the GSoC 2008 for wxPython. The ideas listed here http://wiki.wxpython.org/Google%20SoC%20Project%20Ideas seem to be really interesting.
Particularly, I am interested in passing exceptions from python to the C++ layer and back, numpy arrays as well as working on FloatCanvas.
Below are my proposals as well as some more information about myself and my motivation.
I'd love to hear back! Comments, critique and ideas highly welcomed from all users!
-Matthias
···
---
Proposals:
-----------
My proposal for the exception project is as follows:
1. Consult with Robin about his ideas.
2. Doing a proof-of-concept example. This could probably be decoupled from wxPython itself (only SWIG sandbox code) (1 week)
3. Applying the proof-of-concept to wxPython. I am not sure yet about the complexity involved here. If we can get things to work for example with a %exception statement then this is probably easy. If it needs adjustment for different parts of wxPython it's probably going to take longer. (no time given, first needs consulting, but I estimate this to be around 1-3 weeks)
4. Start work on the numpy array idea. I think Bill Spotz from the SWIG mailinglist already wrote lots of typemaps to use numpy from other projects. This will make wxPython really faster (and more functional) in areas where lots of data needs to be processed (such as images). Also interoparability with PIL would be achieved which is beneficial to user dealing a lot with images. This task can be broken into several sub-components (wx.Image probably the most important one, followed by others such as wx.PointList etc) (2-4 weeks, n-d array support for wx.Image will definately be implemented, other classes will follow as time permits. I'll try really hard to cover all major places where the numpy arrays can be applied within time.)
5. Write demo examples for the wxPython demo which show the features developed. This will be done in parallel to working on the implementation.
(6.) Generalize the exception mechanism developed in (2) if possible and feed the changes back to the SWIG project (also GSoC approved).
I ran myself into performance problems with large arrays and SWIGging them the naive way so I know the pain this can cause.
--
Proposal for the FloatCanvas project:
I think FloatCanvas will benefit a lot from a "polished" look. This will be achieved by using the rather recent Graphics Context.
1. Get more familiar with the FloatCanvas codebase and talk to Christopher Barker and FloatCanvas users about their ideas.
2. Do general refactoring. FloatCanvas consists mostly of two rather big files right now. These could be broken down into smaller pieces to increase code readability a lot.
3. Refactor scaling. This could be done by using established methods such as using the 2d equivalent of the homogenous 4x4 matrices used in 3d transformations (I have written a 3d engine so I am fairly familiar with those transformations). Those matrices can hold scale as well as rotation and position of an objects. A new API could probably be added to FloatCanvas to support using general transformations. Of course the old API could be kept and made deprecated, perusing the new api internally. The matrix API would also benefit from numpys matrix routines which should add some speed boost.
In addition to a matrix api I could add a more flexibly approach where the user can supply a function mapping input coordinates to output coordinates. This is not very fast, so this should probably be optional. It allows for non-linear transforms, too.
Along with this would go a concept of a view/camera (projection).
4. Refactoring to allow a "GC" backend. This will go along with several performance tests so the performance after any change can be directly evaluated. I will keep an eye on creating a preliminary infrastructure for supporting other backends in the future (SVG for example) and decoupling this from the rest. At the same time I'll try to avoid useless over-generalization for possible future non wx-backends.
5. Adding persistance. How users want to do persistance probably differs a lot. Some may want to create simple pickles, others may want to serialize to from/databases (RDBMS / ZODB), XML, SVG, custom formats etc. So there should be some general interface for this. I will write a default backend using either pickles or an xml stream (depending on what users want).
6. Update the current FloatCanvas demo to show off the new features and how to migrate away from the old API (if I'll introduce a new one)
(7. If there is any time left at this stage, I'll start working on an SVG persistance backend)
--
Information about myself
-------------------------
I have about seven years experience programming in C++/C and five years programming python. In this time I wrote several applications (listing the most relevant ones):
- a C++ 3D engine along with SWIG bindings with ~80,000 lines of C++ code (still under development, since 5 years now)
- tools for this engine, partially written in C++ and python
- game on top of this engine, entirely written in python (wxPython, twisted, still under development)
- simple a real-time broker application for stock and futures trading (wxPython)
- a tool for visual programming over a network (wxPython + twisted)
- contract work involving SWIG
As you can see, I am familiar with SWIG (the main tool behind wxPython), C++, python and wxPython itself.
While doing all of these projects I worked together with other people. On the C++ engine I enjoy working together with two artists (and formely another coder), the broker application and swig contract work were also driven by concrete needs of users. That's why I think I can also do something which is beneficial for and usable by the wxPython community.
The visual programming project involved working with OGL. OGL is fairly clumsy in my opinion, stemming from its C++ origins. FloatCanvas often provides a better alternative and seems to be the better alternative in the long run. Since OGL and FloatCanvas are the only modules of their kind in wxPython and provide unique commonly needed functionality it makes sense to persuade FloatCanvas further. It's current drawing style isn't up to par with other drawing kits. Improving this will probably lead to more users taking advantage of FloatCanvas. Persistance adds to the user acceptance of FloatCanvas, too.
I am really motivated doing this work as I have truely enjoyed working with wxPython and SWIG in the past. For me this is an opportunity to work with an established, friendly open source community and to learn new things (not only code related). I am also sure this will benefit the users of this list (which I am frequently reading and sometimes posting to for a few years now). It's also an opportunity for me to give a little back to the community in exchange for what it has given itself.
P.S.: My main development platform is Windows, I hope this is not a problem. I have compiled wxWidgets on Windows before, so I think it should work.
