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.
Thread beginning with comment 235900
To read all comments associated with this story, please click here.
by nicholas on Tue 1st May 2007 00:25 UTC
Member since:

So in *theory* GNUStep can be used as a starting point for commercial developers (Say Propellerheads or Steinberg) to port OSX apps (Say Reason or Cubase) to Linux?

Or would they be better off using WineLib and porting their Win32 versions?

Reply Score: 1

RE: Cocoa
by Johann Chua on Tue 1st May 2007 01:22 in reply to "Cocoa"
Johann Chua Member since:

GNUStep's the better choice.

Reply Parent Score: 2

RE[2]: Cocoa
by Doc Pain on Tue 1st May 2007 18:34 in reply to "RE: Cocoa"
Doc Pain Member since:

"GNUStep's the better choice."

I think that's correct. GNUstep offers good API and framework while looking professional (or everything else you want it to look like). Applications can be developed for both UNIX / Linux and Mac OS X systems with relative few work which is an interesting point if you want to design multiplatform applications (which you cannot do with "Windows" in an acceptable manner).

While I tended to start a new software project (ranging in the sector of medical software, testing and diagnostics) using Gtk and C, I now feel GNUstep and ObjC would be the better choice. ObjC is not that bad and GNUstep even has useful RAD like tools. Personally, I would not think about using something like Wine or Cedega, but that may be different because I do not have to re-use "Windows" stuff. Furthermore, if software does not need to run on "Windows" platforms, why consider it?

Reply Parent Score: 2

RE: Cocoa
by jimcrofty on Tue 1st May 2007 08:53 in reply to "Cocoa"
jimcrofty Member since:

Haven't used Wine in a while but I used Cedega a couple of years back and it was very good (at least for playing Civ + C&C).

While I love my Mac and would be interested to see OSX apps ported, porting Win32 versions is probably a better bet. Porting an OSX app will require a *lot* more work. OSX != GNUStep. They would likely have to port a myriad of OSX libs including CoreAudio, Quartz/CoreImage, CoreData (possibly). That's not counting that fact in the last what, ~6 years the core Cocoa API has moved on beyond the original NextStep/OpenStep spec GNUStep are currently working towards.

Seems sensible to hit the ground running and port to WineLib than re-implement OSX APIs.

Reply Parent Score: 1

RE[2]: Cocoa
by remenic on Tue 1st May 2007 11:15 in reply to "RE: Cocoa"
remenic Member since:

Yeah, porting the win32 API is a lot less work. I mean, it's only been in development for 14 years now, and look how far it already is! It's also used so widespread, and the apps feel SO native!

My money is on GNUStep ;)

Reply Parent Score: 3

RE: Cocoa
by TheRaven on Wed 2nd May 2007 13:45 in reply to "Cocoa"
TheRaven 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

RE[2]: Cocoa
by nicholas on Wed 2nd May 2007 17:30 in reply to "RE: Cocoa"
nicholas Member since:

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. ;-)

Reply Parent Score: 1