www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - GUI library

reply "Tyro[17]" <nospam home.com> writes:
Is there one available for use with D2 on MAC OS X?

Thanks,
Andrew
Mar 25 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-25 15:04, Tyro[17] wrote:

 Is there one available for use with D2 on MAC OS X?

 Thanks,
 Andrew


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
Mar 25 2012
next sibling parent reply Kevin Cox <kevincox.ca gmail.com> writes:
On Sun, Mar 25, 2012 at 11:13 AM, Jacob Carlborg <doob me.com> wrote:


 On 2012-03-25 15:04, Tyro[17] wrote:


 Is there one available for use with D2 on MAC OS X?

 Thanks,
 Andrew


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


I would reccomend Qt as well.  You will get native cross-platform widgets
with great performance.  I am not sure how far QtD is but I know it once
had a lot of development on it.
Mar 25 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-25 17:22, Kevin Cox wrote:

 I would reccomend Qt as well.  You will get native cross-platform
 widgets with great performance.  I am not sure how far QtD is but I know
 it once had a lot of development on it.


I don't think Qt is uses the native drawing operations on Mac OS X.

-- 
/Jacob Carlborg
Mar 25 2012
next sibling parent "Tyro[17]" <nospam home.com> writes:
On Sunday, 25 March 2012 at 15:59:21 UTC, Jacob Carlborg wrote:

 On 2012-03-25 17:22, Kevin Cox wrote:

 I would reccomend Qt as well.  You will get native 
 cross-platform
 widgets with great performance.  I am not sure how far QtD is 
 but I know
 it once had a lot of development on it.


 I don't think Qt is uses the native drawing operations on Mac 
 OS X.


Thanks to you both for your assistance.
Mar 27 2012
prev sibling parent reply "Rizo Isrof" <rizo odis-project.org> writes:
On Sunday, 25 March 2012 at 15:59:21 UTC, Jacob Carlborg wrote:

 On 2012-03-25 17:22, Kevin Cox wrote:

 I would reccomend Qt as well.  You will get native 
 cross-platform
 widgets with great performance.  I am not sure how far QtD is 
 but I know
 it once had a lot of development on it.


 I don't think Qt is uses the native drawing operations on Mac 
 OS X.


Qt does support native drawing operations on Mac OS X since 
4.5.0, when it switched from Carbon to Cocoa as its backend. More 
info here[1] and here[2].

[1]: 
http://labs.qt.nokia.com/2007/06/21/wwdc-qt-carbon-64-bit-and-other-buzzwords/
[2]: 
http://labs.qt.nokia.com/2008/03/03/qtmac-cocoa-port-alpha-released/

  - Rizo
Apr 13 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-13 14:47, Rizo Isrof wrote:

 On Sunday, 25 March 2012 at 15:59:21 UTC, Jacob Carlborg wrote:

 On 2012-03-25 17:22, Kevin Cox wrote:

 I would reccomend Qt as well. You will get native cross-platform
 widgets with great performance. I am not sure how far QtD is but I know
 it once had a lot of development on it.


 I don't think Qt is uses the native drawing operations on Mac OS X.


 Qt does support native drawing operations on Mac OS X since 4.5.0, when
 it switched from Carbon to Cocoa as its backend. More info here[1] and
 here[2].

 [1]:
 http://labs.qt.nokia.com/2007/06/21/wwdc-qt-carbon-64-bit-and-other-buzzwords/

 [2]: http://labs.qt.nokia.com/2008/03/03/qtmac-cocoa-port-alpha-released/

 - Rizo


If I recall correctly I read somewhere that they went back to non-native 
due to some problems with flicker, but that sounds very strange.

-- 
/Jacob Carlborg
Apr 13 2012
prev sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Kevin Cox wrote:

 I would reccomend Qt as well.  You will get native cross-platform
 widgets with great performance.  I am not sure how far QtD is but I know
 it once had a lot of development on it.


AFAIR, QtD is at the alpha stage. It's based on QtJambi, but there is 
another SMOKE generator, which might be worth giving a try.
Apr 13 2012
prev sibling parent reply "Rizo Isrof" <rizo odis-project.org> writes:
On Sunday, 25 March 2012 at 15:14:04 UTC, Jacob Carlborg wrote:

 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
Apr 13 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-13 14:51, Rizo Isrof wrote:

 On Sunday, 25 March 2012 at 15:14:04 UTC, Jacob Carlborg wrote:

 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
Apr 13 2012