Post by Gour
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."
You'll need to read the entire thing.
"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.
Post by Gour
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
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.
Post by Gour
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
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:
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: