wxC & wxD

[Anders F Björklund]

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