Linked by Thom Holwerda on Mon 30th Apr 2007 20:39 UTC
OpenStep, GNUstep The developers behind Etoile have discussed their future plans for the project recently, and have provided a summary of the discussion on the mailing list. The Etoile live CD project will be transferred from Nicolas (due to a lack of time) to Quentin; he says: "I will recreate an environment for building the LiveCD from scratch (will now be built on Ubuntu Feisty Fawn LiveCD). To help in this process, Nicolas sent me the current LiveCD scripts. I hope to succeed in two or three weeks." On Etoile itself: "Focus will be put on core elements like System, MenuServer, Azalea, AZDock etc. rather than polished applications for this release. We don't have enough manpower for now and it's better to have a stable foundation to begin with." The next release is now planned for the coming three weeks.
Permalink for comment 236572
To read all comments associated with this story, please click here.
RE: Cocoa
by TheRaven on Wed 2nd May 2007 13:45 UTC in reply to "Cocoa"
Member since:

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)

Reply Parent Score: 2