GNUstep provides an Object-Oriented application development framework and tool set for use on a wide variety of computer platforms. GNUstep is based on the original OpenStep specification provided by NeXT, Inc. (now owned by Apple and incorporated into MacOSX). We are hosting today an interview with Adam Fedor, of the GNUstep project.1. What is GnuStep and its purpose?
Adam Fedor: GNUstep is a cross-platform developement environment for writting applications and tools modeled after the OpenStep specification released by NeXT Inc in 1994. GNUstep has since commited itself to following the API of the MacOS X (Cocoa) frameworks
2. What is the status of GnuSTEP right now and where would like the Gnu team to bring it? What are the future plans?
Adam Fedor: The non-GUI framework is essentially complete and stable. The GUI system is still evolving, but many improvements are occuring and we make major releases at least every 6 months.
We eventually hope to provide a complete, superior GUI framework for developing intelligent, useful applications. After that we’ll probably work on the applications themselves…
3. Were they any NeXT applications ported over to the GnuSTEP and Linux? If no, why no one took the time to do a simple re-compilation?
Adam Fedor: There have been a few. One notable port is the NeXT Music Kit. Fewer graphics apps have been ported because of the incomplete nature of the GUI. I know of several companies that have or are planning to port their company applications to GNUstep.
4. What are the advantages of Obj-C against C or C++?
Adam Fedor: Objective-C offers a power Object-Oriented model that is much simpler to learn and understand than C++, yet it is still completely compatible with the C language.
One can develope and debug applications faster in Objective-C, as well as easily expand the scope of a project (something that happens often in software developement).
5. Does GnuStep 0.7 changes will be incorporated into a newer version of WindowMaker?
Adam Fedor: GNUstep and Windowmaker are essentially separate developements. WindowMaker is a window manager. GNUstep is for application developement. While it’s technically possible to (re)developer a window manager using GNUstep, there’s little reasons to do this.
6. Does the GnuSTEP API have similarities with the MacOSX API? If yes, do you believe that programmers will try to transition their apps to Linux? If no, are there any steps taken to provide MacOSX API compatibility?
Adam Fedor: Yes. GNUstep follows that MacOSX API as closely as possible.
Am I misreading this or is he suggesting that the Mac OSX api will be available under GNUstep, will this mean porting applications will be easy?
I could of course be getting totally confused.
Their are some issues with the API. The first is binary and language. gcc, the GNU compiler, has support for object-c. I don’t know what compiler Mac OS X uses, but if they use gcc some apps could just run on LinuxPPC. x86 versions, of course, will require a recompile.
Another issue is the GUI API. GNUstep will not have Display PDF, or Quartz, for quite some time. I say this because it has taken them a long time to get Display PS (their version is called Display Ghostscript) working. Now even though GNUstep will not have Aqua this year, GUI apps will still work. When you work with an GUI API like GNUstep or Aqua, you use classes and methods to say, “give me a window here, a text box here and a button there”. The application has no concept of the display engine below. The API is the middle layer between the two. So, on Mac OS X the same app will look blue and transparent and on GNUstep it will look gray and normal.
Look at the classes for Mac OS X and you will see that they mostly start with NS… that is short for NeXTstep. GNUstep classes start the same way. The goal is to have a 100% cleanroom, drop in replacement for the OpenStep (NeXTstep, Mac OS X) API. Why? Opensoure, Free Software, portability.
Here is a follow up if any one can answer. Has it been difficult to get hardware accelleration into Display Ghostscript? Also, the Berlin project promises vector drawing like DPS, but adds to that 3D. Berlin will have hardware acceleration on any OS with OpenGL when combined with a machine with 3D hardware and a proper OpenGL driver. Berlin will certainly surpase GNUstep this year in display technology. Has anyone thought of switching from DPS to Berlin?
Thanks
The Mach “fat” binary format used by OS X is entirely different from the ELF binary format used by Linux on any platform; even on Linux/PPC, apps will require a recompile.
Why, was anyone said that it won’t need a recompilation? Of course and it will need a small porting effort.
There are 2 main apis in Mac OS X, Carbon & Cocoa. Cocoa is the is the OPENstep api implementation in Mac OS X. Cocoa apps , when GNUstep is completed, should be farely easy with most problems related to makefile incompatiblility which utilities are in development to ease this.
Hi,
it is true that DPS is not yet ‘ready’ for daily use. But GNUstep can make use
of different backends ( even switch on the fly! ), so there is a X11 based
backend which works pretty good for most of the applications ( the usual 80/20%
rule… ). So if you need just ‘normal’ gfx capabilities most is already there.
cheers,
-Phil
Hi,
Just a little feedback from a user. I’ve been working on a command line (no GUI) high performance scientific application with Distributed Objects and lots of non-GUI bells and whistles, and the foundation part of GNUstep has been rock solid. I develop on OS X, and then recompile under Linux, and the process has been flawless (the only exception is a Linux 6.2 kernel bug that I can’t blame GNUstep for :-). I’ve been very impressed with the level of code and everything has cross compiled beautifully. I think this bodes well for when the GUI part is complete.
-Miguel
What about Java support in GNUstep? One of my favorite features of Cocoa is the transparent support for Java. Is anyone working on an Objective-C :: Java bridge for Linux?
Look at http://gnustep.it/jigs/
I like GNUSTEP and POSTSCRIPT. Please work faster on porting!!!!!! In return I will port over very good commercials applications from our developer source objects with apis and postscript of openstep 4.2 of intel hp sparc max next motorola. We have important software we can port and download and others to sell also. Why is work so slow? Max are bad for us because we use intel and openstep and apple is bad under microsoft threats to pull out ms office so they can’t release Openstep Macosx for Intel even though I know they have it because somebody said who nos somebody who said that somebody who works there has actually seen steve jobs! rush doesn’t understand how bad is mac and MS Radio guys dumb on this particular issue of thinking
please remove post (bad english
The compatibility issue of display PDF is pretty much moot due to the fact that Cocoa has graphics primitive abstraction using NSBezierPath. Apple discourages editing PDF data directly if it can be done using NSBezierPath.
However while the compatibility issue is moot, the speed issue isn’t
I have been following GNUStep’s efforts since it was first announced around 1994, shortly after NeXT released the OpenStep specification as an open standard.
Since then, the guys at GNUStep certainly did their best to reprogram that specification, however, progress is very slow, due to missing humanpower. Obviously, not enough people have found interest in such an “esoteric” API.
That was rather sade for me, since til 1996, it pretty much looked as if OPENSTEP (the OS) would have been abandoned by NeXT, and GNUStep was the only follow up. Now, with Apple, that has fortunately changed.
However, if not more people will join the GNUStep team, I am afraid that they might not even be able to implement all changes Apple is making to the API, in right time.
I remain very sceptic about the prospect of this project, though I wish them all the best.