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

In article <d1h54c$to2$1@digitaldaemon.com>, BERO says...
>
>http://wxd.sourceforge.net/

woohoo, gj!


- ahiru >(' )

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

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_REGULAR


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

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

Anders F Björklund wrote:
> Note that it is spelled as "Mac OS X", not OX ?
OOps

> 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" ?

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

C# part

    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);
	}

    }

C#'s delegate can directly call from C++ code, but D's not.

C# callback is:
 C++                       C##
 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.

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

	
> 
> 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
> 
someone edited already..

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.

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

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.

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


Seems 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