www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D for MacOSX

reply llothar <llothar_member pathlink.com> writes:
Hello,
is it possible to use D to generate MacOSX. I will generate my own Carbon
bindings, so the question is just about the obj/exe output format.
Jul 11 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
llothar wrote:

 is it possible to use D to generate MacOSX. I will generate my own Carbon
 bindings, so the question is just about the obj/exe output format.
Yes, it is very much possible. (with the usual GDC cave-ats) See http://gdcmac.sourceforge.net/ for a binary installation ? Bindings for Carbon are possible to do, but somewhat complicated by a) the use of macros for assertions b) the framework headers The full Carbon framework also drags in a ton of dependencies, most of which are copyrighted by Apple and non-distributable... I did some older examples* of "hello carbon world" with Xcode and so on, but need to clean them up for the new GDC distribution still. A good thing about Carbon is that it is C only, which makes it easier to interface to with D - than what e.g. a full C++ framework would be ? --anders PS. * Here is one example: http://www.algonet.se/~afb/d/carbon.d
Jul 11 2005
parent reply llothar <llothar_member pathlink.com> writes:
Yes, it is very much possible. (with the usual GDC cave-ats)
See http://gdcmac.sourceforge.net/ for a binary installation ?
Good. To see this. Do you know if there is anybody working on a MacOSX-Intel port. The Intel developer machines are already on the Apple Developer Network.
Bindings for Carbon are possible to do, but somewhat complicated
by a) the use of macros for assertions b) the framework headers
Thats not my idea. I will port the FOX toolkit to Carbon. I already have a more or less clean FOX C++ -> ANSI C layer which then again is used by a GNU SmallEiffel binding. But i want to move my application from Eiffel -> D during the next 2 years, as Eiffel is not a valid alternative for Software Developer anymore.
Jul 11 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
llothar wrote:

 Good. To see this. Do you know if there is anybody working on a MacOSX-Intel
 port. The Intel developer machines are already on the Apple Developer Network. 
The GDC 0.15 build could be for "i686" arch too, if you want the bloat? (but likelier it'll be a separate download, rather than a fat/universal binary with both of the PPC/X86 architectures as is possible to do too) Likewise, I _could_ do a "i386" arch build for Panther using Darwin 7.0 (even though it is *not* supported for Apple's frameworks, since they want to sell Tiger. But remember, *all* Mac OS X versions run on Intel!) It's not a problem. X86 is "just another processor family" to build for. (at least that's what I think, since I don't have $1000 for a test box?) If someone does, let me know and I'll put a X86 binary up for next time.
 Thats not my idea. I will port the FOX toolkit to Carbon. I already have a more
 or less clean FOX C++ -> ANSI C layer which then again is used by a GNU
 SmallEiffel binding. 
Wouldn't it be easier to use a library that does have Mac OS X support ? Or does FOX have any advantages over the other GUI libraries, you think? It would still be great to see FOX supporting Mac OS X, none the less... (just wish that someone could do a port of GTK+2 too, that'd be awesome) --anders
Jul 11 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
I wrote:

 The GDC 0.15 build could be for "i686" arch too, if you want the bloat?
 [...]
 Likewise, I _could_ do a "i386" arch build for Panther using Darwin 7.0
 [...]
 It's not a problem. X86 is "just another processor family" to build for.
In theory, that was... :-) In reality, GDC is still lacking some cross-compilation support to build universal binaries from a regular Mac OS X and picks the wrong compiler. (mostly this comes from the non-standard Makefiles inherited from DMD) Nothing major, but it will take a while to get it to build GDC cleanly. Future discussion on D.gnu --anders
Jul 12 2005
prev sibling parent reply llothar <llothar_member pathlink.com> writes:
Wouldn't it be easier to use a library that does have Mac OS X support ?
Or does FOX have any advantages over the other GUI libraries, you think?
Not if you have around 300.000 Lines of code written with a lot of GUI features. A good application still spends 80% in the GUI part. I tried to port it to Cocoa (under Eiffel) but i even don't think anymore that Cocoa is a good GUI library. You see that it is about 15 years old.
Jul 12 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
llothar wrote:

Wouldn't it be easier to use a library that does have Mac OS X support ?
Or does FOX have any advantages over the other GUI libraries, you think?
Not if you have around 300.000 Lines of code written with a lot of GUI features. A good application still spends 80% in the GUI part.
Sure, I can buy the legacy argument... I thought it was a new project. And it should be easier to port a GUI framework now with the "HIView" hierarchy, than what it was with the old Mac Window/Control Managers. Then again, FOX seems to build its own widgets using only the basics ? (i.e. it works more like Java "Swing", than what Java AWT or SWT does)
 I tried to port it to Cocoa (under Eiffel) but i even don't think anymore that
 Cocoa is a good GUI library. You see that it is about 15 years old.
I think Cocoa is a nice framework and even better now with "Core Data", but it *is* pretty firmly tied to Objective-C and the runtime thereof ? (I know you can write Cocoa using Java, but it has now been deprecated) And of course, it's not portable to other systems - not even "GNUstep". But the amount of things that can be done without coding is impressive. --anders
Jul 12 2005
parent reply llothar <llothar_member pathlink.com> writes:
In article <db061q$eat$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Then again, FOX seems to build its own widgets using only the basics ?
(i.e. it works more like Java "Swing", than what Java AWT or SWT does)
Correct thats why i think it is less work. Adding AppearanceManager painted widgets is then the next step.
I think Cocoa is a nice framework and even better now with "Core Data",
but it *is* pretty firmly tied to Objective-C and the runtime thereof ?
And of course, it's not portable to other systems - not even "GNUstep".
But the amount of things that can be done without coding is impressive.
But i'm not afraid about writing code ? I just find a lot things difficult especially the "Owner Drawn" lists, trees, table cells etc. And still no layout managers .... But this is a D newsgroup
Jul 13 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
llothar wrote:

But the amount of things that can be done without coding is impressive.
But i'm not afraid about writing code ?
Maybe you should be... ;-) Specifying user interface items in an XML format by using a graphical tool is *so* much nicer than having to code it all, piece-by-piece... But this is not the place. --anders
Jul 13 2005