wxC & wxD

[Anders F Björklund]

Gour wrote:
>> If you were to use SWIG, you would still have the same two libraries ?
>> Just that files would be: example.d + example_im.d, example_wrap.cxx
>> (as generated by SWIG from your example.i source file and the headers)
>> whereas they are currently called: wx/Example.d and wxc/example.cpp
>
> OK; but do you consider it would be better not to depend on wx.NET?

At this point in time it doesn't matter, the generated files are
different even if the scripts to generate them are somewhat similar.
The API is also different, from the different languages used and
from this recent push to rename things to be more like rest of .NET.

So it's not really dependent on wx.NET now, even if the wx-c-gen.pl
script and a few other translation details were reused and adapted ?
Other bindings, for instance for SDL and for OpenGL, were generated
by similar perl scripts operating on the original C/C++ header files.

>> The classes already grow an annoying filename addition to their name
>> anyway, unless you add all the classes to the main wx.d file directly.
>> So it probably doesn't matter if wxApp is called "deity.wx_.app.App",
>> as long as you have a top module to import and some reasonable
>> aliases.
>
> Right. My main concern is just whether it is more feasible to provide
> wxD directly using SWIG'S D capability.

Easiest way to tell is to start wrapping a couple of classes, to see ?

%module object

%{
#include "include/wx/object.h"
%}

%include "interface/wx/object.h"

And then use `swig -d -d2 -c++ -outcurrentdir wx/object.i` to generate.

Probably need some kind of namespace workaround to create the modules
as "wx.object" rather than just "object" or to convert the "wxObject".

Eventually it should use <wx/object.h> and copy/fix the interface, but.


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/

Even using SWIG, there's a whole lot of code that needs to be written.


>> When you do the SWIG interface files, you should not use the includes
>> directly since those have a *lot* of platform/implementation details:
>
> I believe that those things should be taken care of by e.g. cmake.

Linking is a whole other issue, this was "just" for determining the
interface files for SWIG (the .i). Probably by combining both wx/*.h ?

>> Instead it's better to use the Doxygen interfaces as the basis for .i
>> Those should focus more on the actual wx API you want to export to D:
>
> Yes. WxPython will also use info from Doxygen.

I think it would be needed to translate it to DDoc for it to be allowed,
but wxD also makes use of Doxygen as can be seen from the API reference.


> So, is wxD going to continue like now, or do you envision some change
> how to proceed for wx-2.9/3.=?

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...

Both wxWidgets and Code::Blocks are Open Source, so if you want to
continue to base the GUI and IDE for the D programming language on
those there's plenty of things that could be improved for either...
The same goes for GCC (and LDC), of course. Maybe even for DMD too.

The wxWidgets roadmap says "We hope to make 3.0 in the spring of 2012."
But as mentioned earlier, using 2.9 should be just fine before that ?

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.
Ditto for the GDC binaries there, that probably need updating both for
64-bit and for D 2 as well as for newer versions of GCC and of the OS.

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 ?

--anders