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."
Its kind of cool that it supports the OS X API, but how useful is that in practice? There's hardly any apps that use the OS X APIs right now, and of the ones that exist the developers haven't really shown much interest in supporting Linux...
Did he say stuff that matters?
I haven't used GNUStep recently, but I can tell you that, unlike KDE or GNOME, GNUStep has the capability to bring real applications to linux land.
There are a lot of NeXT developers who would love to port their applications. It would have been a real coupe if GNUStep was ready for prime time before OS X, but, oh well.
My only concern over it was that it used that dog display ghostscript. If you use Solaris, the Sun XWindow server has builtin support for display postscript. It's too bad the Open Source community has a "{XWindows|Display Ghostscript | | etc} sucks, but it's good enough, so why try to build a replacement" mentality. Fortunately, there are people like Adam who say "Fuck that, I don;t want to wallow in mediocracy".
Long live GNUStep!!
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.
How does this graphics portion of the API compare to MFC?
I'm not a strong GUI programmer, but I've heard people say that MFC is more robust and powerful than the APIs we have in Linux. But I've also heard people rave about programming NeXT.
Is anyone here able to put ideology aside and give a comparison based on real experience?
One thing was done real well. Principle of least astonishment. You were never surprised (or angered) by the way a method call behaved. Everything acted exactly how you would expect it.
This may be technically true, there are some very nice Mac OSX only apps that although not 'big name' are none the less quite nice. The products at Omnigroup are all nice. Stone Studios products are nice but they could use a nice how to book.
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. They both look VERY, VERY cool.
Office for OSX will also be Cocoa native... not that MS will want to empower Linux, but I believe that MS departments will go for profit where ever it is found... Just look at the Mac market back around 96 when every was SURE that the Mac was dead... MS releases a PPC native Office, mainly because Office was pulling in about 400 Million a year on the Mac way back then.
I think the could only be good for Linux... it will hopefully be good for the Mac OSX community. Tools written here will be very portable to the Mac.
Now if Apple was REALLY smart (hey, they could be once or twice a decade), they would support this project in a big way and they would fund the porting of their _very_ nice free development enviornment to Linux... perhaps built on this foundation.
Apple, you could gain HUGE amounts of respect in the linux community by doing this. You will also gain access to more industrial strength Linux tools for OSX, an OS that will be sound at release 10.1 but which will still be in desperate need of diverse apps.
Steven (stupid Ffakr)
I'm not feeling witty so bite me
Why would I want to develop crossplatform applications with GNUStep, when I can use Qt 3.0? Qt supports Windows, MacOS X, Unix/X11, and Embedded. Apps have the look and feel of the native platform (unlike GTK), and no power/speed is sacrificed because the look is emulated, not wrapped (unlike wxWindows). All this using the proven C++ language. This is not vaporware folks. Each supported platform is just that: fully supported and stable.
I can't compare it to the OS X API's, since I have never programmed for a Mac, but doing Qt programming has been easier than anything else I've tried. Check out this page, where customers, some from high-profile companies, sing praise about why they prefer Qt to other alternatives / native toolkits.
Besides the obvious cost of using Qt for commercial development (which should only be a financial issue for individual developers, not companies), what good reason is there to use anything else?
... Photoshop. Illustrator. Office. I consider that a very significant and useful feature. Wouldn't it be interesting if OpenStep provided the doorway for native versions of applications the rest of the computing universe depends on?
I would like to know if there are any IP issues the GNUStep have had, or will have to deal with?
It seems odd to me that they would choose to work in Objective C. If they want the idea to be adopted, if they want their efforts to be worth their while, why not choose a language that has broader support?
Objective-C may have some nice features above and beyond regular C, but if you're going to do work in a relatively obscure language, why not pick one that has better language support for various computing paradigms than popular alternatives? It seems whatever minor quirks of Java and C++ you'd overcome would be less important than being able to draw from a large base of experienced Java/C++ programmers.
I remember watching the development of GNUStep from back when I just started using Linux (95? 96?). It seems to be a project that has been slowly in development for years now, yet unfortunately hampered by a lack of support from the OSS community.
I wouldn't blame anyone, though. Most people are not familiar or even interested in the NeXTStep/OpenStep platform. The technology is definately strange, based on Objective-C and a postscript-based rendering engine, but this platform was (is) years ahead of its time.
I have OpenStep 4.2 for intel, and it is probably the coolest OS ever. At one point I got a copy of an early OS X beta for intel, and it was basically OpenStep 4.2 recompiled with a Macos-looking widget set and a menubar instead of the Wharf ("Dock" in WindowMaker land). The look and feel of OpenStep is far and beyond any UNIX or Windows desktop in terms of sheer quality and useability (many believe the Windows widget set is imitative of the NeXT look to the point that NeXT could have sued Microsoft).
It is sad to think that if Redhat decided to throw its weight behind GNUStep instead of GNOME, we probably would have had a full-fledged, slick NeXTStep/OpenStep/Macos X clone right now layered on top of any UNIX kernel. This is just too bad. I think pretty soon I will reinstall OpenStep 4.2 on my Intel box, and I'm definately investing in one of those G4's to find out what those old NeXT developers (considered some of the most innovative and talented GUI developers in the world) have been up to.
Yes, because C++ is a Turing-complete programming language, you can do anything with C++ that you can with Objective-C.
However, to anyone who has used Obj-C and NeXTSTEP in any depth, your question sounds much like "What's so great about having sex? I can have an orgasm by jerking off, can't I?"
Let me put it this way: in 1989, I knew the Mac *cold*. I switched to NeXT, and it took me about one month to be as productive using the AppKit as I had ever been on the Mac. Within the year, I was at least three times as fast doing any given task.
The only development environment that ever arguably equalled NeXTSTEP for productivity was Smalltalk.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Basically, the only people who can really help on GNUStep are the people who have a fair amount of experience with NeXTSTEP or its successors.
When people without this experience try to help, you end up with a disaster like Sun's OpenStep on solaris.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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.
I would add, that the NeXT frameworks had a remarkable degree of consistency in naming and functionality across classes. If NSArray had an -enumerator method, so would NSSet.
After a few weeks of using the AppKit and Foundation Kit, I found that I could very often guess what a method was called, and be right.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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
Scott Stevenson
Tree House Ideas
That the OpenStep logo actually looks like a stealth bomber?
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
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
Scott Stevenson
Tree House Ideas
There aren't many at the moment, beacause they really became finalized in march, but there are some things like FileMaker Pro that are completely cocoa, and work impressively well. Oh, and Maya is completely Cocoa.
This is the fifth post or so that has named Carbon apps, and claimed they were written in Cocoa. I wish I knew what the source of misinformation was.
I have repeatedly been told from people that should know (Maya fanatics) that Maya is definitely a Carbon app. This was done because they needed to use C++ frameworks (Cocoa is currently ObjC and Java only). I don't know about FileMaker, but I would be pretty surprised if it was Cocoa. Who told you these were Cocoa apps?
- Scott
Scott Stevenson
Tree House Ideas
There's hardly any apps that use the OS X APIs
There are actually quite a few brand name apps that have been ported to Mac OS X, and many more are in progress. Probably more than people outside the Mac community would guess. Corel is on the ball -- Bryce and Painter are ported, Microsoft has already released Explorer and Office 10 is almost ready. Macromedia already has Freehand out, and both it and Adobe are working furiously to port everything. Other stuff that's done: Quicken, Maya, quite a few games, and tons of other stuff that I'm forgetting.
These have all been ported to Mac OS X APIs. The problem is (for GNUStep users, anyway), these apps use the Carbon APIs, not Cocoa. Cocoa is GNUStep's counterpart.
- Scott
Scott Stevenson
Tree House Ideas
GOD! How I miss programming on the slab. I firmly believe the programming world has gonew backwards in the last decade. The AppKit was soooo far ahead of its time we're not even there yet.
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...
/.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.
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, 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,
- Scott
Scott Stevenson
Tree House Ideas
We all know [computer] languages are designed with a specific purpose and usually excel in those designated areas.
The reason I use C++ is because it is a multiparadigm language (i.e. functional, oop, & generics) "Modern C++ Design" shows the wonderfull and elegent power of generic programming (templates.)
Obj-C has piqued my interest - maybe those expercienced in Obj-C can answer some questions.
a) "In what areas does Obj-C do better then C++" ? Is it only cleaner syntax?
b) "What can Obj-C do that C++ can't?"
I know that since it is based on C. it will have the same weaknesses as C, but I'm more interested in what Obj-C strengths are.
Cheers
One of the problems in porting software to a platform is finding people with both the time *and the skills* to do it. If MacOS X becomes popular with developers, there will be a large base of people familiar with programming with the API. If a chunk of these people also play with Linux then you are increasing the chance of these people doing ports to your favourite platform.
Phillip.
Property for sale in Nice, France
- Apple's Cocoa APIs allow you to write code in Java as well as Objective C, since both of these are highly dynamic object-oriented languages . I am not sure if the thingies that allow projectbuilder to compile java and seamlessly link java into objective c are part of apple's GCC additions or not.
- For as long as i've followed GNUStep, my interpretation of "stuff" has been that they have a goal of remaining as close to the Mac OS X/NeXT API as possible (for the purpose of facilitating portability)-- but that this is not their primary goal, andthey have no problem with diverging if they feel it is technically important. With this in mind, how will the fact that Apple has switched to a PDF-based display model-- one that seems to me to be slightly less technically elegant, and ccloser to the hardware-- while GNUStep has stayed with display postscript affect things? Will this make porting *much* more difficult? Which would be better, making a DPS-like library for os x or a Quartz-like library fopr GNUStep?
If i don't get any answers here, maybe i'll go ask the GNUStep mailing list...Will it at some point be possible to use java to write GNUStep apps the way you can currently use java to write Cocoa apps, could apple's own GCC code or whatever be used to facilitate this, and does anyone know if there's been any progress on the attempts to make it possible to write Python code for either?
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
It has a very tiny memory footprint
You can configure it to do almost any thing you want
You can group many windows into one frame, which helps to manage lots of netscape, xterm, and other app windows.
It supports windomaker dock apps
A gui that isn't all gooey. I like that.
The middle mind speaks!