Gour wrote:
Here's a more complete example of what it would look like in the end:
http://svn.wxwidgets.org/svn/wx/wxPython/trunk/src/
http://wxruby.rubyforge.org/svn/trunk/wxruby/swig/classes/
Thank you.
Of course, you don't *have* to wrap all the classes or methods ?
One could start with the ones that are likely to be used from D.
Even using SWIG, there's a whole lot of code that needs to be written.
Sure. We just wonder if using route will be more effective in the long
run?
Automation is surely the way to go, the only question is whether it
should be a custom script or if a (patched?) SWIG would be better.
BTW:
If it helps, there's a Doxygen parser (for the XML output) in the
docs/doxygen/scripts directory that could be used to start it off:
cd docs/doxygen
./regen.sh xml
python scripts/make_bindings.py --swig --output_dir=bindings \
out/xml/classwx_app.xml
The generated SWIG bindings are for wxPython, but I suppose you
could adopt the swig_tools.SWIGBuilder to generate some D SWIG ?
python scripts/doxymlparser.py --report out/xml/classwx_app.xml
I don't plan to do anything with it, I put it up on github so that it
could be forked and maintained if there are any bugfixes etc needed...
OK.
It's perfectly doable to continue to use the current
wxd.sourceforge.net even with wx 3.0 and D 2.0, so I think I will
just leave that up as-is.
OK.
Just that I won't have much time to actually maintain it, myself.
When starting up the "wxD2" or "$deity" - or whatever the new project
would be named, it could probably do more changes than just use SWIG ?
Thank you for making it clear. ;)
Whether it's about hosting or organization, or something different.
--anders
