Linked by Thom Holwerda on Mon 30th Apr 2007 20:39 UTC
Thread beginning with comment 236572
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Thanks for the info, it's very interesting.
GNUStep is always something that has been "Looks nice, will have a play one day" but "one day" never seems to arrive. :-)
(Lack of) Time is usually the key factor in this unfortunately. :-(
ps You are not alone in hating the Win32 API. ;-)




Member since:
2005-08-11
In theory, GNUstep is a better choice. GNUstep makes it very easy to move Cocoa code to *NIX, and the emphasis on the separation of model and view code in OpenStep (the specification of which Cocoa and GNUstep are implementations) makes it pretty easy to maintain separate UIs for OS X and *NIX.
There are two main problems. First, a lot of applications mix Cocoa and Carbon code. Carbon and Cocoa objects are typically equivalent, and foo(X) in Carbon often has an analogue in Cocoa as [X foo]. Things like this are easy to get around with some #defines in GNUstep. Most developers don't use these, however, they use the bits of Carbon that aren't in Cocoa. These generally don't exist in GNUstep, and need to be replaced by other code.
The other problem is that GNUstep only implements Foundation (GNUstep base) and AppKit (GNUstep gui). Some extra frameworks are available; we have a compatible implementation of the AddressBook framework in Étoilé subversion, for example. Things like CoreImage or CoreAudio, however, are very OS X only (for now...) and projects like Cubase are likely to have heavy dependencies on things like QuickTime, which is far beyond the scope of GNUstep.
If you have an existing codebase that runs on OS X and Windows, the odds are that you are using Carbon a lot more than Cocoa, so WineLib would probably be a better choice. If you are starting now, I'd suggest you develop with GNUstep (porting from GNUstep to OS X is easier than the other way around). There is a bundle available (somewhere) that attaches the menu to the active window for people using broken UI paradigms, and if you include that with your Windows version it should look similar to a Windows app. If you haven't tried it yet, have a play with the OpenStep API (Cocoa or GNUstep), because it really is a joy to use in a way no other API I have used is. Frameworks like Qt try to implement something like an Objective-C runtime on top of C++, while OpenStep just uses a flexible, late-bound, dynamic language directly.
Of course, I'm biased, since I never could stand the Win32 API...
David (Étoilé developer)