Adam Fedor of GNUstep Says Stuff

JgiSaw writes "GNUstep provides an Object-Oriented application development framework and tool set for use on a wide variety of computer platforms. It is based on the original OpenStep specification provided by NeXT, Inc. (now owned by Apple and endorced into MacOSX). OSNews is hosting an interview with Adam Fedor, of the GNUstep project, where Adam mentions among others that GnuStep has support for the MacOSX API too, which will make porting MacOSX applications to Linux much easier."

Re:macos x api

[Noer]

Well, there are some quality apps such as Omniweb and the Stone suite, but this won't help bring big-name *commercial* apps to Linux (apps such as Photoshop, MS Office, etc) as those are mostly written to the Carbon APIs, rather than the Cocoa APIs that OpenStep is related to.

Re:You should think the other way around

[Anonymous Coward]

Objective C (especially used with the NeXTStep/OpenStep API) does make coding a breeze. The OOPness is more similar to java than C++ (actually, it's more similar to smalltalk, since that's what it's based on).

There are still a number of Next and Former NeXT developers who can tell you how elegant it is.

Re:There are major apps... coming soon ;-)

[znu]

Illustrator, Quark 5 and Office will not be Cocoa applications. Most major Mac OS X apps will be Carbon apps, because it's much easier to move existing Mac apps to Carbon. Perhaps major new apps will be written in Cocoa, but major new apps don't come along all that often.

GNUStep is still a pretty big deal. This is a kick-ass API. Assuming the open source equivalents of Interface Builder and Project Builder can match or beat the Apple tools, GNUStep will be the absolute best way to develop Linux applications.

QT For Mac

[Matthias Wiesmann]

A few months ago, a demo of QT for OS X was released, I was very intersted, so I tried it out. Honnestly the thing was rather dissapointing, at least for me.

• The Aqua widgets are not mapped to native widgets, but simply QT widgets with a skin. The problem was that it was very visible, they acted wierd and where rather unresponsive (more than the native widgets, I have a relatively fast machine). I think one thing that would be nice, would be to do the same trick than apple did for swing, use native piers, at least for the Aqua look.
• It crashed quite a lot...
• Inter-application support was very bad. Copy paste was shoddy: somtimes you would get garbage, text would get accents garbled, (I'm swiss/french, so this is very annoying), no possibility of copy/pasting images. Same for drag/drop. I don't remember if printing was working, but I think it was simply not there...
• OpenGL and direct graphics (the asteroid game) where OK, but then again, Mac OS X has direct OpenGL support.
• The toolkit did no seem to use OS standart mechanism. For instance, under OS X, preferences are not stored in an invisible file, but in some kind of centralized database using a reverse DNS notation (like java classes).
• It reminded me of the times when MS pushed for Office application for the Mac based on a litteral port of the Win32 code (Word 6), it was slow, and looked and acted as a disguised windows application.
• QT for Mac is not available freely (like it is for X11), just when Apple decided that they would give away all the devellopement tools for free.
• Of course I'm aware that this was a beta, and many OS X APIs are not stable, but in it's current state, Qt did not look to me as a viable option for serious desktop applications.

Re:Support for MacOS X compatable API means ...

[TheInternet]

Unfortunately, you're not looking towards the future: Adobe, Microsoft, and several other major software manufacturers have promised versions of their major titles for the Cocoa API, several of which have been demonstrated live in the last few months. I encourage you to look at both Microsoft's Macintosh pages, as well as Adobe's web site.

I'm not sure what you'd be referring to. The products that Microsoft has announced for Mac OS X -- Office 10 (for Mac OS X only, not Mac OS 9/8) and Explorer -- are both Carbon apps. They have not demoed or confirmed any Cocoa apps in the works. They may eventually, but it's debatable if there is reason to do so anytime soon if Apple continues to improve Carbon. The story is pretty much the same on Adobe's side. They have demoed InDesign, Illustrator, GoLive and some others. They have also release a native version of Acrobat. But these are all Carbon apps. They have not talked about any Cocoa apps.

Aside from the fact that it is generally easier to port existing large Mac apps to Carbon than rewrite them in Cocoa, Micrsoft and Adobe still have the vast majority of their customers on Mac OS 9/8. They are probably not too keen to do massive forks at this point. The fact that the Mac OS Toolbox and Carbon APIs are similar makes it fiscally feasible to address both Mac OS 9 and Mac OS X markets.

There are two ways to use Carbon. You can create a single Carbon binary that executes on both Mac OS 9/8 (old technology) and Mac OS X (Mach/BSD). However, this somewhat limits how much you can do on the Mac OS X side. The other option is to use Carbon only as a porting bridge. You don't end up with two separate binaries (one for OS9, one for OSX), but you still get two relatively similar code bases with similar API calls. This is what many developers have opted to do since it allows them to build a better Mac OS X app without having to completely rewrite their software. Microsoft is currently doing this with Explorer.

There actually is a third reason to use Carbon -- it's a C/C++ framework. Maya opted to use Carbon for this reason. Cocoa apps can currently only be written in Objective-C and Java. There is talk about resurrecting Objective-C++, though.

Carbon and Cocoa apps can look essentially identical to the untrained eye. Both make calls to the same core frameworks. They both provide protected memory spaces, preemptive multitasking, and access to Quartz. They are peers in many ways. "Classic" is the compatibility environment in which a Mac OS 9 virtual machine is launched to run old Mac apps that have not been ported to either of the new APIs. While Cocoa and Classic apps use Aqua UI widgets, Classic apps do not. They generally have the grey chizeled look of Mac OS 9.

By the way -- the Finder, Mac OS X's file manager/shell is written in Carbon, as is the event manager. And based on Apple's statements, it looks like they have done a lot of work on Carbon for the emminent Mac OS X 10.1 release. Several upcoming Carbon Mac OS X apps require 10.1.

- Scott

All Carbon apps

[TheInternet]

On the near horizon, Adobe Illustrator 10 and Quark 5 are nearing release (both demonstrated at MWNY in July) and they are both, to the best of my knowledge, Cocoa native. [...] Office for OSX will also be Cocoa native

I'm not sure who has given you this indication. Office 10 is most definitely a Carbon app. You can have Carbon apps that only run on Mac OS X and not Mac OS 9. Office 10 is one such app. Is this the source of the confusion?

- Scott

Lineage

[TheInternet]

Remember, Mac OS X is essentially NeXTSTEP

Perhaps if you look at it in terms of only Mach/BSD and Cocoa. There is tons of stuff there that was never in NeXT, though: Carbon, Quartz, system-level QuickTime usage, AppleScript/AppleEvents, I/O Kit, Mac OS 9 compatibility.

It borrows some lower-level from NextStep, some higher level stuff from Mac OS, and makes something brand new. GNUStep apparently only attempts to address the NeXT side of the world, but a lot of the mainstream items will make heavy use of the Mac side of things.

- Scott

Clarification on Cocoa vs. Carbon apps

[TheInternet]

I've posted similar messages in this topic, but wanted to get it up to a higher level to resolve a lot of the confusion...

Even in a finished state, GNUStep does not do as much to get apps to Linux as some people seem to think Or, at least, not the apps they have in mind. If you're at all familiar with Mac OS X development [apple.com], you know that there are four APIs that the system considers "native": Cocoa, Carbon, Java and BSD. Any program written to these APIs receives it own 2GB of protected address space (yes, even individual Java apps), as well other modern OS features. Classic is the Mac OS 9/8 compatibility environment. Sort of an "emulator on steroids," to use a cliche.

GNUStep provides a implementation of the OpenStep spec, which is what Cocoa is based on. Theoretically, this means that Mac OS X apps written in Cocoa can be easily ported. But the vast majority of the brand name apps have been or are being ported to Mac OS X are written in Carbon. The long list of Carbon apps includes:

- Office
- Explorer
- Macromedia Freehand
- Acrobat
- GoLive
- Illustrator
- Bryce
- Corel Knockout
- Corel Draw
- Painter (Corel/MetaCreation)
- Maya
- Quicken
- Netscape

Quite a few people have posted messages to this topic mistakeningly claiming some Carbon apps were actually Cocoa apps, including Office. I'm not sure what would have caused this confusion. Part of the problem may be that you cannot tell the difference between a Cocoa app and and a Carbon app unless you really know what to look for. Both use Aqua UI widgets. Some individuals might also be making the assumption that if an app is "Mac OS X only" (meaning does not run on Mac OS 9), then it must be written in Cocoa, which is not true.

So why write in Carbon, you ask?

Most existing Mac developers port apps to Carbon because it's easier than a complete rewrite in Cocoa. It also means that developers can keep reasonably similar (in some cases, identical) code bases for both Mac OS X and Mac OS 9. This is important because most of their customers will be on Mac OS 9 until the transition is complete. Alias|Wavefront was not porting an existing Mac app, but opted to use Carbon for Maya because they have existing C++ code (and developers?) they want to use. Cocoa frameworks can currently only be accessed from Objective-C or Java.

Over time, you may see developers do rewrites in Cocoa, because in many ways it is a better environment. Ther resurrection of Objective-C++ would probably help this. But the more Apple does to improve and refine Carbon, the less immediate the need will be to do rewrites in Cocoa.

So that's that. Now, getting back to GNUStep....

From this interview, it sounds like the GNUStep folks have the Foundation side of Cocoa pretty well in hand, but it looks like AppKit (all of the GUI stuff) is not done. But even after they finish everything that has been around since OpenStep, I'm curious how they're going to resolve all sorts of new stuff. Specifically, I'm thinking about things like QuickTime (used for much more than video), Quartz (transparency/compositing, PDF generation/manipulation, text rendering), and even stuff like AppleScript/Apple Events. These are things that Mac OS X developers are and will be using, but I can't imagine they're going to be very easily to implement from scratch on the GNUStep side. I understand that there are perhaps counterparts, but how comparable will they be? I'm genuinely curious about this.

I praise Adam and his colleagues for their efforts. But at the same time, /.ers shouldn't let their expectations get out of hand. At the moment, GNUStep is no more helpful in getting MS Office to Linux than is Mac OS X's use of BSD libraries.

- Scott

Re:There are major apps... coming soon ;-)

[Matthias Wiesmann]

While there is probably less incentive to do it, as there are less Macintosh applications around, it will probably be an easier project than wine.

• Carbon is probably a simpler API than win32, it was simplified to make the port to OS X possible.
• Carbon is very similar to the classical macintosh API. There is already an open-source project to support this API: Mace [cjb.net]
• While the Carbon API is not well documented, it's ancestor classic was very well documented.

It must be noted that on Mac OS X, carbon calls are not mapped on cocoa calls. Both API access some private low-level API. There has been a lot of discussion about what API is more native, and it seems the answer is: none.