wxC & wxD (was Re: moving wxd to github)

[Anders F Björklund]

Gour wrote:
> I haven't build wxD yet, but just curious...you say that the sample
> depends on wxc\display.cpp, but I thought that wxc stuff belonged to
> wx.NET port, while the wxD site says: "Newer wxD version (0.10) has been
> updated to wxWidgets 2.6.4 and linkable with wxWidgets 2.8.4 as well,
> and is now based directly on the original wx classes since the
> previously used wx.NET was not being maintained anymore."
>
> Please advise?

You'll need to read the entire thing.
http://wxd.sourceforge.net/#libraries

"wxD is not a D port of wxWidgets, so it uses the C++ libraries. It is 
composed of two parts: (2 static libraries)

     * wxc is a C++ library which exposes the wxWidgets API as a 
collection of D-friendly functions (extern "C").
     * wxd is a library written in D which parallels the wxWidgets (C++) 
classes, ported over from wx.NET (C#).

It's then linked to the regular wx libraries from wxWidgets, [...]"

So wxD (the project) consists of two sub-libraries: wxc and wxd.
Whether it's libwxc.a or wxc.lib depends on the platform/compiler.


wx.NET is sorta/kinda maintained again now, much like wxD itself...
It changed name to "WX.Net", in some attempt to make it more .NET
(probably a really bad idea, as it hinders porting from wxWidgets)
Fortunately D has the "alias" keyword, instead of such renamings.

http://wxnet.sourceforge.net/


> Edit: Now I see that wxC is/was project meant to provide basis for
> wxEiffel (& wxHaskell) bindings...but seeing it's not really maintained
> it seems to be dead end. My proposition is research about the
> possibility to do wxD straight from the SWIG and its D support since
> present approaches does not, I'm afraid, promise bright future.

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

http://www.swig.org/Doc2.0/SWIGPlus.html

You would also get all the function-pointer fun (like in Derelict),
why there is the extra intermediary module to hide the dlopen junk.
The wxD code uses regular bindings, so it would just link directly.
But one could probably move the extern(C) declarations, if desired.

http://svn.dsource.org/projects/derelict/trunk/docs/derelictify.html

> Morever, I believe there are not so many wxD-2.8.x applications written
> and it's reasonable to start working on 2.9/3.0 not caring much about
> older releases.

You could always put it in some namespace, like Derelict/Deimos does ?

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.


When you do the SWIG interface files, you should not use the includes
directly since those have a *lot* of platform/implementation details:

http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk/include/wx/   (1561)

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:

http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk/interface/wx/  (350)

--anders