digitalmars.D - [ANN} wxD: wxWidgets bindings released
- BERO (11/11) Mar 19 2005 http://wxd.sourceforge.net/
- ahiru (3/4) Mar 19 2005 woohoo, gj!
- clayasaurus (2/17) Mar 19 2005
- =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= (34/44) Mar 19 2005 Note that it is spelled as "Mac OS X", not OX ?
- bero (105/131) Mar 20 2005 one is D string, and another is callback.
- =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= (10/24) Mar 20 2005 OK, I didn't have time to run a diff then, since all
- =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= (19/27) Mar 20 2005 Seems like the templates are tripping bugs in vanilla GCC 3.3.5,
- Walter (3/14) Mar 19 2005 I'm cross-posting this to digitalmars.D.announce
http://wxd.sourceforge.net/ wxD is wxWidgets bindings for D language. wxWidgets is cross-platform GUI toolkit, which supports Windows, Mac OX X, *nix like OSs such as Linux,FreeBSD with X11/Motif/GTK. wxD is delivered work from wx.NET bindings 0.61. Under development. Currently only checked on Windows platform. Some example program crashed. Threre are another same name project http://wxd.sourceforge.jp/ but it looks stopped. BERO
Mar 19 2005
In article <d1h54c$to2$1 digitaldaemon.com>, BERO says...http://wxd.sourceforge.net/woohoo, gj! - ahiru >(' )
Mar 19 2005
Please make future announcements in d.D.announce newsgroup : ) BERO wrote:http://wxd.sourceforge.net/ wxD is wxWidgets bindings for D language. wxWidgets is cross-platform GUI toolkit, which supports Windows, Mac OX X, *nix like OSs such as Linux,FreeBSD with X11/Motif/GTK. wxD is delivered work from wx.NET bindings 0.61. Under development. Currently only checked on Windows platform. Some example program crashed. Threre are another same name project http://wxd.sourceforge.jp/ but it looks stopped. BERO
Mar 19 2005
BERO wrote:wxD is wxWidgets bindings for D language. wxWidgets is cross-platform GUI toolkit, which supports Windows, Mac OX X, *nix like OSs such as Linux,FreeBSD with X11/Motif/GTK.Note that it is spelled as "Mac OS X", not OX ? About the Mac: A big problem at the moment is that main wxWidgets library requires the standard Apple GCC to compile (since the Carbon framework uses some Apple features), but the GDC patches don't work with that compiler tree, but must be applied to the standard GNU GCC... (due to Apple's having some "Objective-C++" patches) And these two are *not* link-compatible, which sucks:section's (__TEXT,__eh_frame) type S_COALESCED does not match previous objects type S_REGULARThe "easiest" here is probably to patch in the rest of the required Apple support (Pascal strings, constants, etc) into the GNU GCC 3.3.5 tree and then use the custom GDC/GCC version. But it should be possible to use the Motif version on Apple's version of X11, in the interim, so it's possible to test this D library on Mac OS X and with GDC already... Just mentioned this, in case anyone wonder about the Mac... (every D code using Carbon framework has these problems)wxD is delivered work from wx.NET bindings 0.61.I see that you decided to fork a "wxc" for wxD, from the "wx-c" library in the wx.NET project... Was there some other reason, in addition to D strings ? Seems like lot of work (especially with wx.NET updates), just to change from "const char *" into "struct dstr" ?struct dstr { unsigned length; const char* data; };There's also a bug here, "unsigned" should be "size_t" or it will not work with 64-bit and not match D arrays ? There are some other code changes needed for GDC, but probably better to take those to the wxD sourceforge ? http://sourceforge.net/projects/wxd/ You might also want to edit the Wiki4D pages about it, at: http://www.prowiki.org/wiki4d/wiki.cgi?AvailableGuiLibraries http://www.prowiki.org/wiki4d/wiki.cgi?wxD Glad to see someone is still working on wxD, good job ! --anders PS. wxWidgets supports Mac OS 9 too, but GDC does not...
Mar 19 2005
Anders F Björklund wrote:Note that it is spelled as "Mac OS X", not OX ?OOpsI see that you decided to fork a "wxc" for wxD, from the "wx-c" library in the wx.NET project... Was there some other reason, in addition to D strings ? Seems like lot of work (especially with wx.NET updates), just to change from "const char *" into "struct dstr" ?one is D string, and another is callback. wx.NET C++ part typedef bool (CALLBACK* Virtual_OnInit) (); class _App : public wxApp { bool OnInit() { return m_OnInit(); } int OnExit() { return m_OnExit(); } void RegisterVirtual(Virtual_OnInit onInit, Virtual_OnExit onExit) { m_OnInit = onInit; m_OnExit = onExit; } ... } public abstract class App : EvtHandler { private delegate bool Virtual_OnInit(); private delegate int Virtual_OnExit(); private Virtual_OnInit virtual_OnInit; private Virtual_OnExit virtual_OnExit; ... protected App() : base(wxApp_ctor()) { app = this; virtual_OnInit = new Virtual_OnInit(OnInit); virtual_OnExit = new Virtual_OnExit(OnExit); wxApp_RegisterVirtual(wxObject, virtual_OnInit, virtual_OnExit); } public virtual bool OnInit() { return wxApp_OnInit(wxObject); } .. } wxD C++ part typedef bool (CALLBACK* Virtual_OnInit) (dobj obj); typedef int (CALLBACK* Virtual_OnExit) (dobj obj); class _App : public wxApp { bool Initialize(int& argc, wxChar **argv) { return m_Initialize(m_dobj,&argc,argv); } bool OnInit() { return m_OnInit(m_dobj); } int OnExit() { return m_OnExit(m_dobj); } void RegisterVirtual(dobj obj, Virtual_OnInit onInit, Virtual_OnExit onExit,Virtual_Initialize initialize) { m_dobj = obj; m_OnInit = onInit; m_OnExit = onExit; m_Initialize = initialize; } ... } D part extern (C) { alias bool function(App o) Virtual_OnInit; alias int function(App o) Virtual_OnExit; } public abstract class App : EvtHandler { ... extern (C) private static bool staticOnInit(App o) { return o.OnInit(); } public bool OnInit() { return wxApp_OnInit(wxobj); } } m_Oninit() -> delegate -> OnInit() (delegate automatically set instance?) D' s callback is: C++ D m_OnInit(dobj) -> staticOnInit(dobj) -> OnInit() additionally, there are some missing or spell miss function in wx-c. why wx.NET works? I think .NET is late binding, therefore when call native function and can't resolve the function name , runtime error will happen. D resolve link phase, so I can find and fix it.D's "int" is allways 32bit (even if 64bit machine, I think) accoding to D abi specification, A dynamic array consists of: 0: array dimension 4: pointer to array datastruct dstr { unsigned length; const char* data; };There's also a bug here, "unsigned" should be "size_t" or it will not work with 64-bit and not match D arrays ?There are some other code changes needed for GDC, but probably better to take those to the wxD sourceforge ? http://sourceforge.net/projects/wxd/ You might also want to edit the Wiki4D pages about it, at: http://www.prowiki.org/wiki4d/wiki.cgi?AvailableGuiLibraries http://www.prowiki.org/wiki4d/wiki.cgi?wxDsomeone edited already..
Mar 20 2005
bero wrote:I see that you decided to fork a "wxc" for wxD, from the "wx-c" library in the wx.NET project... Was there some other reason, in addition to D strings ?one is D string, and another is callback.OK, I didn't have time to run a diff then, since all the filenames had been changed from .cxx into .cpp... Thanks for answering.Yes, "int" is always 4 bytes. However (void*) and .length is not ? Guess it depends on how you want the struct to work, in the end... --anders PS. Think I have all the patches done to GDC shortly, then I'll do another try of recompiling wxMac and testing wxD 0.02 with it.There's also a bug here, "unsigned" should be "size_t" or it will not work with 64-bit and not match D arrays ?D's "int" is allways 32bit (even if 64bit machine, I think) accoding to D abi specification, A dynamic array consists of: 0: array dimension 4: pointer to array data
Mar 20 2005
Think I have all the patches done to GDC shortly, then I'll do another try of recompiling wxMac and testing wxD 0.02 with it.Nope, it seems like a no-go:/usr/bin/ld: Undefined symbols: wxEvtHandler::GetClassInfo() const wxObject::GetClassInfo() const typeinfo for wxAppConsole typeinfo for wxObject typeinfo for wxThreadSeems like the templates are tripping bugs in vanilla GCC 3.3.5, and some parts of wxMac (i.e. wxWidgets for the Mac) are using Objective-C++, which doesn't mix all that well with D in GCC... So, C++ libraries like wxWidgets work with the system compiler and D libraries work with the GDC compiler - but trying to mix them both into one binary does not work. At least not just now. And this was *after* adding the following Apple features to GCC: - Framework headers (e.g. "#include <Framework/Header.h>") - Pascal strings ("\phello"), required for Carbon - No warnings about missing newline at EOF - Apple build version (__APPLE_CC__) Using MinWin or other "native" D library is probably a lot easier than trying to link a C++ library to a D library... (not that wxD isn't a good idea on other OSes or anything) Too bad that all existing GUI libraries seems to be in C++ ? (cross-platform frameworks, that is, not the native headers) Neither wxD (wxWidgets) or DUI (GTK+2) is working on Mac/GDC. --anders
Mar 20 2005
I'm cross-posting this to digitalmars.D.announce "BERO" <berobero users.sourceforge.net> wrote in message news:d1h54c$to2$1 digitaldaemon.com...http://wxd.sourceforge.net/ wxD is wxWidgets bindings for D language. wxWidgets is cross-platform GUI toolkit, which supports Windows, Mac OX X, *nix like OSs such as Linux,FreeBSD with X11/Motif/GTK. wxD is delivered work from wx.NET bindings 0.61. Under development. Currently only checked on Windows platform. Some example program crashed. Threre are another same name project http://wxd.sourceforge.jp/ but it looks stopped. BERO
Mar 19 2005