OSNews

Isn't there a script to convert those?

This is coming very soon.

GJC

Actually, it was rather difficult to convert nibs before (they used a binary serialization). But now, you can tell IB to save in XML... So as greg is saying, "it's coming soon" on gnustep too (parts of the classes are done already).

I think the biggest problem when porting Cocoa apps is that many also use Carbon. That's the case with the Firefox/Camino OS X port if I'm not mistaken.

err, no. Cocoa and carbon are different things. Carbon really shouldnt be used anymore. Everything i have written has been pure obj-c and Cocoa.

I know they're different things, but (for example) both IM clients I looked for used it (fire, adiumx), firefox uses it, etc.

It's probably not that hard to ifdef carboa out, but it is getting used.

Actually, Adiumx doesn't use carbon. What it uses is Objective-C++, which is a completely different thing. The problem with Objective-C++ is that the GNU gcc doesn't support it, as opposed to Apple's version of gcc. Apple has submitted many patches to gcc for O-C++, and they will be included in the official tree very soon (or maybe they have already). So Adium can surely be easily ported when the official gcc gets objective c++

Objective-C++ is indeed in the current gcc cvs... so normally, the next official gcc release should have it. That will indeed be very helpful for GNUstep -- we'll be able to easily port many Cocoa applications that use C++ (WebKit, etc.)

Nicolas, do you know if anone has tried:

1) building GNUstep on Mac OS X with Apple's GCC, and then build Webkit/other apps against GNUstep (and not Cocoa)?

2) Building Apple's GCC on a GNU-based system, and then porting apps that way?

GNUstep works on OSX itself using X11.app under Panther; under Tiger I think there's some problems (perhaps solved now though). It's useful to port applications, as you can have them aside, or even for running Shark on a GNUstep app

Now, you couldn't use Apple's gcc, because Apple didn't include the GNU ObjC runtime, and GNUstep didn't compile using the NeXT ObjC runtime. So you needed to recompile a FSF gcc anyway.

Camino OS X Port? Camino is OS X only, and is a Cocoa Application

I know, I threw that in because I mentioned Firefox.

The point is, from what I remember reading a while ago, it's not easy porting Camino because it uses Carbon too.

http://www.caminobrowser.org/features.html

It's a Cocoa App, not Carbon, and apparantly porting Cocoa app's are relatively easy to port to OS X for x86

"i looked at the camino/gecko sources a couple of days ago. since camino
depends on gecko you will first have to port the gecko engine to
GNUstep.Gecko itself seems to use Carbon for the Mac-implementation.
Camino itself uses Objective-C++."

http://lists.gnu.org/archive/html/discuss-gnustep/2003-08/msg00041....

Webcore should be harder to port than I've thought, they didn't use openstep text system because Cocoa's text system implementation is too slow than GNUstep's and that's why Webcore's text is crappy (buggy) and losing many functionalities of openstep text system.

Actually I wish this DE would take off very soon, instead of seeing the endless attempts of KDE/Gnome to match it's functionality.

GNUstep could have been a really good desktop environment (well, I know, strictly speaking GNUstep is no desktop environment) two or three years ago.

Guess what people said two or three years ago ? the same thing. GNUstep progress slowly, but it progress. As long as there is contributors.

Nowadays there simply is no need for it in the face of the very fast evolving GNOME and KDE desktop environments. Even XFCE is moving ahead in a very fast pace. I suspect GNUstep could be interesting to those using Mac OS X. But hey, that's a dwindling minory ...

That's what you say. But not everybody is happy with GNOME and KDE. As you say, other projects like XFCE still gather enthusiast users. There's perhaps a reason..

Now, GNUstep is not _only_ a possible fundation for a desktop -- it's also a cross-platform environment, and many persons are currently interested in GNUstep because of that (OSX devs wanting to port apps on Windows, Linux).

So there's more in GNUstep than just a linux desktop -- it's first and foremost an incredible programming toolkit, and Gorm is one of the Best RAD tool I know of. Secondly, it's also very interesting for its crossplatform possibilities. And its compatibility with Cocoa.

The "GNUstep desktop" that you can have by using GNUstep apps together is something that I personally like a lot, but that's not the only thing GNUstep do..

Nevertheless, a "GNUstep desktop" has a totally different "feel" than what GNOME and KDE propose. Instead of monolithic apps, you have many small apps that actually *cooperate* together easily, via for example the service menu. That's why I think there's still an interest in developing a desktop based on GNUstep (see http://www.etoile-project.org).

Large parts of OS X already have free software implementations, including the core operating system and the development framework for GUI apps (GNUstep). In the case of the core OS you don't even need a clone, as Darwin is free, but you're better off using GNU/Linux which is better supported than Darwin (both on desktop and server), and it's pretty much compatible too.

The difference is that GNUstep runs on top of X11; making a free replacement of whatever Apple uses instead is huge work (big emphasis on the word huge), and the advantages are questionable. Not to mention X11 has a lot of support (many people working on it), and to write something exactly like Apple's with no documentation is... not fun.

What's left is the desktop, in other words, a set of GNUstep applications designed exactly like the ones in OS X (Finder, iTunes, etc). There are people working on desktop GNUstep applications, the plan is to make them better than the OS X ones.

The one question probably left on your mind is whether it's possible to have binary compatible OS X apps with, say, Darwin+X11+GNUstep. That I'm not sure... it seems Apple breaks binary compatibility a lot though.