I think these are the choices on Mac OS X:
* gtkD - Bindings to GTK. Does not use the native drawing operations of
the operating system. Available on all platforms.
http://dsource.org/projects/gtkd
* QtD - Bindings to Qt. Use the native drawing operations of the
operating system (I think). Available on all platforms. Not sure if this
is developed any more.
http://dsource.org/projects/qtd
* wxD - Bindings to wxWidgets. Use the native drawing operations of the
operating system. Available on all platforms. Not sure of the status.
http://wxd.sourceforge.net/
It would also be possible to use Cocoa, as you do with Objective-C, but
that wouldn't be very practically. There's also a DMD fork that directly
supports interfacing with Objective-C:
http://michelf.com/projects/d-objc/
--
/Jacob Carlborg

It would also be possible to use Cocoa, as you do with
Objective-C, but that wouldn't be very practically. There's
also a DMD fork that directly supports interfacing with
Objective-C:
http://michelf.com/projects/d-objc/

Why do you say that the usage of Cocoa through the D-ObjC bridge
would not be very practical? What are the possible limitations?
- Rizo

It would also be possible to use Cocoa, as you do with Objective-C,
but that wouldn't be very practically. There's also a DMD fork that
directly supports interfacing with Objective-C:
http://michelf.com/projects/d-objc/

Why do you say that the usage of Cocoa through the D-ObjC bridge would
not be very practical? What are the possible limitations?

What I was referring to above was to interface with Objective-C without
using a bridge. That is just very verbose and tedious. There's a lot of
code to write just to create a new class, call a method and so on.
The problem with the D/Objective-C bridge is bloat. A Hello World
application written using the bridge takes around 60MB. It also slows
down compilation time.
--
/Jacob Carlborg