Slashdot Mirror

Close. OS X doesn't have three user interfaces, but three programmign interfaces (APIs). There is BSD, Carbon, and Cocoa. BSD is what it sounds like; Carbon is a port of a cleaned up version of the current Mac OS toolbox (the API Mac OS uses); and Cocoa, is simply the next version of the OpenStep API, which is object oriented, and quite sophisticated. Carbon allows pretty easy porting of current Mac OS applications to Mac OS X. The Carbon API also exists on the traditional Mac OS, so you can produce a binary for Mac OS 8 - 9 and Mac OS X with a compiler flag, and making changes to have it run on System 7 shouldn't be too hard either. It's for these reasons many Mac OS X developers coming from previous Mac development will use Carbon. You're getting Carbon confused with Classic. Classic is an appliation which runs on Mac OS X which runs a copy of Mac OS 9 in emulation for the purpose of running non-ported prorgams. Carbon isn't as a nice of an API as Cocoa is, but it does take advantage of all of the advantages Mac OS X has over it's predecessors. When MS says they'll have Office 2001 on OS X, they're most likely to use Carbon, for the above reasons. What does this mean in the context of getting MS apps on Unix in general? Not much. Carbon and Cocoa are portable APIs, and do not require Unix at all. ARDI is trying to implement Carbon on top of Linux/X and Windows toward the end of portable programs. Apple themselves has an older version of the Cocoa API available on Windows, as a part of WebObjects development. My point? Mac OS X doesn't use X, but it's own Display PDF window server. But that doesn't matter at all. It all depends on whether or not the API is implemented on the target platform. If an app was written in Cocoa for Mac OS X, there's a good chance, sometime in the future, they could very easily be ported to Linux and other Unices via GNUstep, an implementation of the OpenStep/YellowBox/Cocoa API, which is coming along slowly, but very surely. Porting an app from Mac OS X/Cocoa to Linux/GNUstep shouldn't be that hard, as it's a high-level API. The companies writting these apps simply need an ecomical incentive to do so.

The short answer is that there is currently no "complete" solution. By "complete", I mean:

• Comprehensive APIs with UI support.
• RAD tool.
• Good database access.
• Actually shipping and available right now.

Before the knees of Java-heads start jerking, let us examine how the obvious candidate falls short:

100% Pure Java
Though Java written only to Sun's API is in theory useable for a cross-platform app, there are a few pragmatic issues -- the APIs are very poor and complex, the UI layer (Swing, née AWT) sucks ass, VM idiosyncracies are rampant, and performance may be a problem (though improvements are constantly being made). On the up side, there are several RAD environments for Java, your development and deployment platforms can be (more or less) different, and database access is reasonably solid (JDBC).

More or less everything else out there is incomplete in terms of the three main criteria you have stated (UI APIs, RAD tool, DB access).

Apple's Cocoa/Yellow Box/OpenStep Frameworks
For just the Mac, the Cocoa frameworks that are a part of Mac OS X are by far the best solution. They are vastly more sophisticated, complete and robust that anything else on any platform (with the possible exception of some SmallTalk environments). Cocoa has top notch UI support (the AppKit), an eminently usable RAD environment (ProjectBuilder, InterfaceBuilder et al.) and DB access that is about 2 generations ahead of anything else (Enterprise Objects Framework). Cocoa is also completely cross-platform technically, and has been so for several years (at one point running on Mach (m68k, i386, hp-pa, sparc) & Windows (i386). So what's the problem? Apple does not currently license Cocoa for anything other than the Mac, and has indicated no plans to do so. This prevents people for whom cross-platform development is essential from using what is without a doubt the most advanced application development environment in existence. Yes, it sucks. Harrass leadership@apple.com about it.

So what are other people in the same predicament doing? Though there isn't currently a perfect, off-the-shelf answer, there are many things one can do to get close:

• Ensure that your app design & architecture are modular - break all the database stuff and business logic out into a "model", which has no UI and can therefore be highly portably written in Objective-C, or C, or C++, or whatever. Java, with JDBC, may be viable as a cross-platform solution here.
• Abstract all UI and "controller" behavior into as thin a layer as possible, so that it is easier to implement it against different UI layers (Carbon, MFC, GTK, whatever). The main obstacle you face here is having to implement the UI code natively for each platform. The various abstraction layers that are commercially or freely available tend to take a least common denominator approach, and hence sacrifice quality, speed and flexibility. Unless you don't care about you UI very much, they are not all that useful.

Other random notes: If GNUStep ever gets close to complete, your Cocoa code should trivially port to anything supported by GNUStep. Currently, the non-UI layer (Foundation) is production quality. Also, if your database schema is complex/demanding, you really, really should take a look at EOF, which is now a part of Apple's WebObjects product.

Handy-dandy URLs
Mac OS X Developer Documentation
GNUStep, a free implementation of the OPENSTEP spec.
Java 2 Documentation

GNUStep provides a series of tools for checking and working on these proplist files, which somewhat resemble configuration for perl scripts IMO. Anyway, it's a good format that seems to be what everyone drooling about XML was after, and it's got a longer history. It's worth looking at if you happen to like the way wmaker's configs are stored.

you won't be able to run Mac OS X binaries on Free- or NetBSD because they won't have access to the Carbon, Cocoa, or Quartz API's.

They can do Quartz/Cocoa once gnustep is done.

"There's very little progress on GNUStep!"

I assume this will see more progress as fellas will want to run their OS 10 apps without rebooting their boxen.

Quartz and Cocoa? Aren't those already being cloned?

You are right that the modern version of the classic MacOS libraries (Carbon) libraries won't be available (yet?) on GNU/Linux. But don't forget that the new Cocoa library is just a modern variant of the NextStep/OpenStep libraries that are already available as GNUStep that is under active development.

Display Ghostscript, a part of the GNUStep project is coming along, slowly but surely. - what I want to know is: Seeing as Ghostscript supports PDF as well as PS, will we therefore see a Libre version of the Display PDF technolgy that Quartz is based on ???

Display Ghostscript, a part of the GNUStep project is coming along, slowly but surely. - what I want to know is: Seeing as Ghostscript supports PDF as well as PS, will we therefore see a Libre version of the Display PDF technolgy that Quartz is based on ???

A few?

Everything that makes it a Mac is closed. Carbon, Cocoa, Quartz, Quickdraw, etc. - it's all proprietary. What is "open" is Darwin - a mach kernel with a BSD personality - and that's nothing new. I use "open" in quotes btw because not only is it (obviously) not Free Software I don't think it even qualifies as Open Source. Read the APSL if you don't believe me - check out the termination clause in particular. Now I personally don't have any patents to infringe, but I'd still be an idiot not to recognise a poison pill when I saw it.

This is not to criticise Apple. What they are doing makes perfect sense from their position. It's smart business - smarter than their competition, and it will probably do exactly what they want it to do - improve their profitibility. What doesn't make sense is for the community to be such suckers for it! If MSFT had been smart enough to do the same thing with NT, how many of us would have bought it? How many of us were so enthusiastic when Sun released a few things under a similar license, the SCSL? But because it's Apple somehow it's different?

The same Apple that's threatened themes.org and GNUStep recently? What is wrong with this picture people?

What started the whole GNUstep/OpenStep API debate in the first place was Steve Jobs telling the CEO of Spindletop (http://www.gnustep.com/) that he was stealing Apple intellectual property by distributing GNUstep.

Lucas Wagner (lwagner@spindletp.com), the said CEO of Spindletop and GNUstep hack, told him that it would be a great benefit to Apple if GNUstep and Apple could work together with Apple to mutually promote their technology. Spindletop, of course, would distribute it. Steve Jobs didn't like this and said it was blatantly stealing Apple intellectual property.

i think GNUstep and Spindletop have both been really favorable to Apple, and this came as a bit of a shock to everyone involved.

I have spoken with Lucas and he has been pretty positive about the situation. He told me that he knew, when he began the company, this issue would arise, so it's good that the project is getting it over with now rather than later, when GNUstep will be "conscious". he didn't want to comment about any further actions from Apple, probably for legal reasons.

from what i can see on gnu.gnustep.discuss, RMS has been contacted about the issue. Development on GNUstep has temporarily halted as they try to sort out licensing issues. it looks like there might be something else that might be going on that nobody's speaking about, but I'm not sure.

On the one hand, it's fair enough that Apple graphics (perhaps nee NeXT) are Apple's, but there are rumblings that Apple wants to get "medieval" over this. There has been a "reaction of silence," as well as more vigorous reactions.

The distressing part, described in this article, is that it appears that access to the OPENSTEP API may not be as open as everyone would wish to believe. To wit,

This document sets forth the OpenStep application programming interface (API). You may down-load one copy of this specification as long as it is for purposes of study only. We look forward to licensing third parties to create original implementations of this API. No such license is granted or implied by the publication of this specification. If you would like information on obtaining such a license, please contact NeXT at OpenStep@NeXT.COM.

Of course, the most distressing part is this message purported to have come from Steve Jobs, where the salient bit reads: From: Steve Jobs Sent: Monday, April 03, 2000 10:19 AM To: Lucas C. Wagner Subject: GNUstep Lucas, As you may know, Apple owns the Cocoa and OpenStep APIs, and will not feel great about others using its intellectual property without premission. Best, Steve

Open is as open does. If Apple winds up suing anyone over GNUstep, I'd say that tells you how committed they really are to "open source."

As I understand it, Darwin is essentially OSX, sans Quartz and the MacOS compatability layer.

First of all, I think we should give credit to Apple for doing this. Yes, I know it's not GPL. I am not sure but I would hazard a guess that the Apple Public License is NOT a certified (by OSI) Open Source (TM) licence. However, this is a great start. We should not flame Apple for not using the GPL but instead encourage them and other companies to do the same. As an aside, anyone know why the didn't just use a BSD license?

Finally, could anyone tell me if they know whether or not OSX is OpenStep compliant? ie, when Quicktime for OSX is released, would it be possible to run it under GNUstep? And further, what are people's opinions on OpenStep/GNUstep? I have been interested lately, and I think that given all the discussion going on lately about cross platform compatability, we should just go ahead and have all the distros be OpenStep compliant. If you would like more information, check out the GNUstep website.

BTW, if any Apple people are reading this, go to the GNUstep website. They're moving right along on the OpenStep spec, including the new routines introduced by MacOS X. :^)

This is probably more a GTK question, but here goes:

There are currently a couple of projects that intend to bring Display Postscript to Linux (DPS/X and gnusteps display ghostscript). IIRC Gtk+ 1.4 will be more easily portable to other platforms.

The question is: would it be possible to extend GTK+ and Gnome to base it on the vector model of DPS, a la Quartz on MacOSX? Maybe it would be useful in the areas where Gnome could use some more work? (printing model, fonts, anti-aliasing)

Also, a bit related, do you see Gnome being a X-only thing, or do you imagine it being ported to for instance embedded applications, experimental environments (Berlin anyone?) or even (gasp) windows?

At the GNUstep project, we've chosen to use GNU/Linux as the groundwork for GNUstep simply because Darwin is governed by the flawed and perverse APSL license. Building an open-source ANYTHING atop Darwin is still governed by Apple's "revocation" clause, and they can take Darwin from you or forbid you from using it at anytime by claiming that you're infringing on their intellectual property.

Non-skeptical supporters of Apple would have you believe that the "new" Apple would NEVER do such a thing like this. Once again, they're blinded by the simple fact that Apple is using "open-sourcing" loosely as a marketing technique, not as a philosophy. The people who are volunteering for Darwin are wasting their efforts, simply because Apple annexes and appropriates the code to sell as if it were their own. Like it or not, under the APSL, the intellectual property issue with Darwin is a one-way door: they can keep theirs, you can't have yours.

Spindletop recently has already gotten into trouble with Apple over intellectual property for pledging to make a distribution of GNUstep that uses compatible technology with Mac OS X. In this case, it was because Apple didn't like how some developers for GNUstep modified old NeXT icons, and threatened to sue Spindletop for having "Apple intellectual property" on their website. Fortunately, they're committed to building GNUstep upon GNU/Linux and the GPL, not to Darwin, as their rights to use it could be revoked in an instant and could take months, up to a year to get it back through the legal system (if ever).

Yet another victory for GNU/Linux and the power of GPL.

Don't trust Darwin, don't use it, don't even touch it. Most of all, don't distribute it or support it. If you like the technology involved, support the GNUStep Project, support Spindletop, and support the GNUstep developers.

The whole point of a GUI is this: I start up an application I've never used before, and it works the way I expect it to; it looks familiar, little guess work, I can quickly begin using the application in the way it was intended. Keyboard, mouse, file access, printing, all the same. Mac has this, Windows has this. Linux? The user is at the mercy of the developer. The value of choice associated with the Linux desktop is a complete facade. If the app was written using the GTK, it will only interact with the Gnome desktop, Gnome File access, Gnome help browser, and it will only listen to the Gnome configuration. If it was written using QT, I'm most likely forced to interact with KDE File manager, KDE Help browser, KDE configuration etc... I have NO choice. And if it was not written in either? I'm screwed. Each new application is a whole new set of problems for the user.

It's funny that if people need a good example of an Intuitive and mouse friendly desktop, they need look no further than WindowMaker. In fact, the state of the Linux Desktop would be downright pathetic if it was not for the wonderful work coming out of the WindowMaker and GNUstep camps. (That config util is a work of art! And the file manager, sexy! Now there's the compelling reason I need to get my Mom to switch to Linux)

Perhaps if the Gnome and KDE developers had to eat their own dog food and not be allowed to use the command line for ANYTHING, we might start to see some of Linux's desktop problems solved; less theme support, and more functionality. I know that they don't, because of the little things; you can't search through list boxes, list views, and tree views by typing the first few letters of the thing you're looking for. Such a simple yet vital feature, completely overlooked. How about screen corners and edges for optimized mouse use? Hardly utilized (Gnome not at all, KDE a little) Sure, these things are trivial to implement, but that fact that these things were overlooked in the first place means that we've got a long way to go before we see a usable Linux Desktop.

...

(I don't mean to come down so hard on KDE and Gnome, they both have many great features. I just think that some basic, fundamental functionality has been overlooked. A single point of configuration for starters...)

Hrmm the arguments for that are a lot less strong than for opening source code. In Apples old business model this would make no sense whatsoever, and although they are using more commodity hardware lately to lower their R&D costs, I'm still not sure it would make any sense for them.

Just be happy with the source guys. If I understand this right it should be a great boost for GNUStep right? Any hackers out there that want to see linux or *BSD becoming a real player in the desktop market should be paying attention.

GNUStep is seeking developers.

The OPENSTEP API also addresses problems still facing GNOME and KDE, such as cut & paste, and the hideous font support inherited from X, among other things. While X's selection-based clipboard system is great for text, it makes no attempt to handle any other content, like images, sound, or formatted text. I don't know how GNOME/KDE apps handle this, but many aps have a private 'clipboard' which only functions within that program, preventing, say, cutting an image from the GIMP and pasting it into a WordPerfect document. The pasteboard in OPENSTEP, IIRC, provides a MIME-type-based board which all other OPENSTEP apps can access.

Also, the Display PostScript (DPS) system which OPENSTEP is built on makes sophisticated graphics output simple to implement, and also provides consistency between what comes out of the printer and what shows up on the screen (WYSIWYG ;-). On most Unices, a completely different font set is available for X programs than there is for the PostScript engine (be it GhostScript, DPS, or a printer), so it is difficult to get real WYSIWYG apps under normal X. Also, antialiasing could concievably be built into the DPS engine, and with all the OPENSTEP apps using DPS, you could get a very nice display.

When GNUstep shapes up to be a full OPENSTEP implementation, it will provide an elegant basis for both application users and developers. With Linux being the buzzword it is now, developers will probably move to the OPENSTEP API when they find they can produce the same program for both MacOS X, which is shaping up to be a big consumer OS, and Linux, which wants to be the same.

I am also working on the concepts of a networked vector-based user interface system, where the graphics is based on SVG. The project would become much more than just vector graphics. Very early stage, no webpage. Mail me if you are interested in participating.

I tried to Nominate GNUstep, but most people would apparently rather stick with a bad rip-off of Windows (itself a bad rip-off of NeXTSTEP/MacOS ), that will get developed regardless of any award.

GNUstep has come a long way, and could really use the Spotlight and Money. Not to mention the real power Linux/BSD/Hurd could have with a set of Libraries and Development tools based on OpenStep.

It's too bad the most vocal members of the ./ community seem to be;

A) A bunch of kids who while they more than likely rebel from their mainstream communities, choose to conform with whatever the current "Hip" (which for some reason seems to be whatever is Windows-Like) open-source software is. (I guess they just trade one conformity for another)

B) The I hate Microsoft/Bill Gates/Windows at all cost types, who again for some reason seem to have as their goal, replication of the Windows paradigm. (Albeit Pro Gratis)

C) The I will trade REAL POWER for a cool looking but almost non-functional windowing theme.

Now for the rest of you whom I haven't offended, I would enjoy seeing a discussion on the relative Merits of why KDE/GNOME deserves more attention than GNUstep. That is, from those that actually understand the issues involved.

Go ahead, flame away, moderate me down, in other words, prove my point.

Big Z

...I don't give a fuck, God sent me to piss the world off... --Eminem

Apple engages such fierce loyalty because it has (according to many) a superior user experience. As the primary differentiator for thier product (Mac OS/Macintosh computers) it makes sense for them to protect it. Whether they are legally or morally entitled to such protection are two seperate issues.

If an enterprising group of people with a lot of time on their hands reimplmented the MacOS X apis (Carbon & Cocoa) on top of Linux (see GNUStep for the Carbon APIs), and coded a user environment that mirrored the look and feel of aqua (including the dock, finder etc) would Apple be ethically entitled to sue? What about morally?

GNUstep has come a long way, and has the potential of allowing for easier development of more robust applications for "The Movement".

Note:

• GNOME Canvas ;
• It's not clear what there may be that is equivalent with KDE, but there will likely be something, whether in KDE or in Qt;
• GnuStep will support whatever the underlying infrastructure does, and it would make a lot of sense to get Display Ghostscript to do anti-aliasing...

Long and short is that it may be quite appropriate to have antialiasing managed within application libraries as opposed to directly in X.

Since Sun obviously can't be trusted to do the right thing as far as opening this platform up I don't install any Java VM on my Linux boxen. Support an open object API for Linux, support GNUstep.

Java is over. The future belongs to Objective-C.

Night

That appears to be the Qt Way of handling printing.

It is interesting to contrast with other methods that have been used historically and recently:

• NeXtStep, and now GNUstep, use Display Postscript
• Adobe has restricted future access to commercial DPS, and hence Apple OS-X plans to use PDF as a display substrate to replace DPS.
• The GNOME Project has created an imaging model that seems to parallel Display Postscript that, as the GNOME Canvas, is also displayable.
• Less well-known is libprint

It is not clear whether or not KDE is using the QtPainter facility, or whether there is need for something like GNOME Canvas...

• Between the KDE Two Conference material and KDE 2.0 Technology Overview, it appears that there is a proliferation of messaging systems.

  It is evident that the C++-based CORBA options are pretty slow, and thereby not acceptable for mass use; barring that, has there been any consideration of using a messaging system that is in use elsewhere, so as to both have evidence that it works, as well as a reduction in the proliferation of new APIs?

  What comes to mind are:

  • Lightweight Distributed Objects (LDO), submitted as an IETF draft, and
  • HTTP-SOAP, also an IETF draft
• Has any consideration been made of using some of the configuration libraries and data formats already available, such as:
  • ACAP, which has an IETF draft
  • libPropList which is used by GnuStep and OpenStep as well as by WindowMaker.
  • Ted Tso's .ini file reader?

It is such a shame when new formats have to be designed and managed, when debugged code already exists to implement these sorts of things.

BTW, the NeXTStep Environment is pretty much the MacOS X Environment, they both follow the OpenStep spec.

More info is on:

www.gnustep.org

• Java

  There seems to have been something of a "trainwreck" with respect to Java. There are lots of "nearly done" Java environments out there, including Kaffe, GCJ, Jikes, "Blackdown," and likely others.

  Unfortunately, none are truly useful without some combination of classes (ala GNU Classpath) and some combination of AWT/Swing. And that has been rather less rapidly forthcoming in the "reasonably free form" that is necessary in order for it to be ubiquitous enough for people to really use it to deploy applications, or to use it as a layer on which to build further infrastructure like EJB.

  Is anybody near to deploying a complete "libre" Java for Linux?

• System Config Tools

  There's Linuxconf. There's COAS. There's cfengine. And Ganymede (tho it needs Java; see above...) and bunches of other system config tools one one degree of incompleteness or another.

  Big, expensive things like UniCentre are also getting ported, although they're not likely of great interest on the home front.

  Is there any intent to try to have some useful protocols to allow intercommunications of some of these systems, or to perhaps pick an existing one rather than recreating the wheel?

• Testing/Standards

  There has been some lipservice about Linux Standard Base (LSB), but it is not evident that anyone has either deployed substantially changed systems as a result of attempting to conform to some common guidelines, nor to actually provide ways of conforming systems to standards.

  There are lots of tools out there to run systems through automated test suites; that is apparently one of the major tasks of one ACLs for Linux project. In other contexts, we find ANSI Common LISP Conformance Tests. The folks at Cygnus run EGCS through testing, and provide EGCS Test Suite Results. Greg is being used to validate that GnuStep conforms to its documentation.

  ... And every "dot zero" release of Red Hat Linux fills many with fear as it tends to at least appear undertested.

  And then there's the Extreme Programming approach (particularly associated with Smalltalk) where one of the core requirements is of Continuous Integration Tests that are integrated in with the development process.

  But it is, often enough, not clear that people are depending in much more than merely the notion that Because it's Open Source, naturally bags of people will want to spend their weekends testing my code.

  We badly need to have some regression tests so that some testing takes place as distributions are constructed. Debian does some of this with dpkg-related tools; it is highly unfortunate that similar tools have not cropped up around RPM.

  Question: What are you doing to help contribute to the public body of test suite code?

As a WebObjects developer, I think it would be 'insanely great' if Apple could find a good business reason to Open Source WebObjects.
For that matter, I don't really see what would prevent some enterprising developers for making a clone. The back-end parts of WebObjects are already there with there with GNU-Step. The WebObjects specific parts consist of only a dozen or so classes. The TOUGH part would be replicating something like Enterprise Objects Framework (EOF) which is the magical part of the whole system that maps the underlying database to the web application.
Sounds tough, but not impossible. In any case, I believe WebObjects is a good model to base an Open-Source Web-Application framework on. Once you have that, you'd use an easy time putting together an e-commerce package.

Ideas? Comments?

Excellent post! I'm glad to hear other ex-NEXTSTEP developers feel the same way about Apple's acquisition and slow (de)evolution/Mac-ification of NeXT. I thought _I_ and my fellow NS developers were the only bitter cynics ;-)

NEXTSTEP was best suited as a high-end development platform, NOT a watered-down end-user designer's toy.

Judging from the Rhapsody DR and MacOS X betas we've used, Apple can only slow a quick, nimble system with more bloat and excess UI BS - second to MS of course. Support for legacy MacOS via Carbon is an absolutely pointless venture, and Apple should _never_ have dropped DPS.

In their effort to bring something that is probably incomprehensible to the typical MacOS user, they are alienating the core NEXTSTEP developers who felt that OpenSTEP, DPS and ObjC was the shape of better things to come...

Ah well, I for one have seen the light, and now am using Linux (on Alpha) and developing for the GNUStep project, which I feel heralds OpenSTEP technologies in the true spirit of NeXT.

Why submit _MY_ hard work and _contributions_ to the whim and fancy of Darwin/Apple/APSL? We've already seen how they've bastardized NEXTSTEP...

Have you looked at GNUstep? It's not finished yet, but it's moving along quite well and should be ready for real use sometime in the first half of next year. Hopefully.
With that, you have a GUI that measures up to Next, and a development environment that should be close, though some tools might be missing, I don't know what NeXT has/had in the way of tools that isn't being cloned.

• The Ancient Past

  In the beginning, Berlin was a project started by some Assembly-Language "uberhackers" that really disliked X, who had the notion that they could somehow write a windowing system that would be so fast that it would somehow displace X.

  In that "distant past," there was much unfriendly flaming, and there were "dueling web pages" between myself and some Berlin folk. My page has since evolved into On the Thesis that X is Big/Bloated/Obsolete and Should Be Replaced, which is rather less "anti-Berlin" now.

  Acrimony arose over a generally "uncooperative" attitude; the designers were quite prepared to eschew CPU architecture portability, only to ever run on IA-32, quite prepared to eschew networking support, never to be able to display apps remotely, and quite prepared to ignore any and all existing GUI APIs, requiring that all-new apps be deployed.

  The original grouping of designers largely evaporated; they seemed to get the beginnings of a font renderer working, but apparently little else.

  I get the impression that there was some politicking along with the GGI Project that was involved in the "staff turnover;" 'tis not completely clear...

• Berlin: The New Generation

  A largely new generation of folks came along, bringing a somewhat more cooperative spirit, and an interest in being hugely "buzzword-compliant," between "being 3D-compliant" via OpenGL, network transparent via CORBA, and by the same token, as architecture independent as C++ and GGI get you, and language-independent (sort of) via UNICODE.

  I had a nice chat with Graydon Hoare last year in Atlanta; they hadn't gotten too far, but certainly had a more useful attitude.

  In particular, they are now not presenting the former, laughable, message that "X is Dead, And Berlin Is About To Replace It."

• My Take on Why They Haven't Progressed Quicker

  After about 3 years, you'd expect there to at least be a text editor or something available. At this point, they're fairly happy to now have some apps that can display widgets that show that there's some working code.

  I would suggest that they are still labouring under some significant handicaps as compared to some of the alternatives, and am skeptical that there is a good likelihood of success:

  • They can't attract effort to produce applications until they have a functioning environment, but can't get a functioning environment without considerably more effort.

    This is a vicious circle; it's hard to attract developers to a system that doesn't work yet, and other projects like GNOME and KDE, as they do function today are vastly more attractive, as well as being vastly less risky propositions.

    This effect is vastly magnified when you consider that commercial enterprises are investing considerable effort in X-based efforts.

    The high probability of failure completely discourages commercial investment of time/effort/money.

  • Unlike other projects that represent improvements alongside of X, Berlin depends on a whole lot of components getting developed. This magnifies risks further.

    The fact that the GGI project developed a library to allow GGI apps to run atop X means that at least that forcible dependency has been cut, but there's still just too many things that need to work for Berlin to work.

    Contrast this with GNUstep, which, it seems to me, has a strategy more likely to succeed.

  • GNUstep is based on an API that is known to be technically and economically viable, namely OPENSTEP.
  • GNUstep requires one "partially unavailable" component, namely the still-being-developed Display Ghostscript substrate.

    It is thus based on the use of a substrate that is feasibly run on X, but which, unlike Motif, doesn't force vast amounts of X dependancies onto programs, it would be conceivable for X to be replaced, eventually, by Display GhostScript Running On Something Else. (Similar is actually true for some of the major "X" GUI toolkits like Tk, GTK, Qt, and FLTK, which all can run on things other than X...)

Good News Even If The Big Project Fails

• There may be components that are of value.

  For instance, they may wind up producing a font rendering engine that could be useful elsewhere.

• The learning about how to use CORBA to build a graphical environment may help steer other projects towards good/feasible ideas, and away from infeasible directions.
• There may be some useful IDL definitions.
• Some of what appears valuable in Berlin is the recasting of Fresco ideas.

  It is arguable that the adoption of Motif (with sundry ugly implementationness as well as proprietariness) over Fresco is part of what has set back progress in X development for a goodly five or so years. (I'd argue that...)

You're right, one of the cleanest apis (and languages :-) I saw.

Look at www.gnustep.org, the GNU implementation of it. It's finally nearing usable state with the 0.6 "dawn" release. Good luck to them.

People use BASIC because they don't know any better and/or they are lazy. The same thing goes for using the proper 'Too' and punctuation. ;-)

I think Apple is finally doing the right thing in letting Yellow Box sell itself. Most long-time Apple developers were freaking over the prospect of having to recode for Yellow Box. Voila, we get Carbon and they are happy. Check out StepWise though to see just how many quality Yellow Box Apps are already shipping for Mac OS X, an OS not even due to be delivered until early 2000. Too bad on the Yellow Box for NT licensing front though. I will personally bet that the problem there is Adobe and not Apple.

Even if Yellow Box should tank the API is alive and well, getting stronger each day. Check out
GNUStep or the GNUStep NewsWire for details. At bare minimum the fellow asking the original question needs to take a look at this.

GNUstep is an Open Source (LGPL) implementation of OpenStep.

Also, OpenStep's Objective-C programming interface is really elegant, and it performs pretty well.

And since Objective-C is a strict superset of ANSI C, interfacing with C (and C++ code) and wrapping an interface around other code is really easy.

Another library worth looking into is OpenStep; specifically the ApplicationKit. This toolkit is what NextStep has evolved into. Even though it is quite old as far as X11 toolkits go, it is surpisingly well designed, OO from the core up and very MVC.

Warning though, the default bindings are in Objective C, an OO C derived language distinct from C++; ObjC has a distinctly Smalltalk flavor about it.

GNUstep is a GPLed clone. I haven't tried it so I can't comment on the quality.

Somewhat off-topic, the OpenStep Enterprise Object Framework is the best toolset/framework for working with databases I've seen.

I strongly encourage you to take a look at the Mac OS X Server programming tutorials on Apple's developer web site (in particular the Discovering OPENSTEP tutorial), and then at the state of GNUstep. GNUstep is really picking up steam, and is an implementation of probably the most elegant object-oriented framework that ever made it into wide distribution.

From a technical standpoint, the OpenStep frameworks really leverage the dynamic nature of Objective-C. People have written interfaces for other languages (Perl, Tcl, Python, Apple even did Java) to the OpenStep frameworks but by and large the best way to write OpenStep programs is to just use Objective-C. Since it's a strict superset of ANSI C, that's not so bad; you can even interface it with C++ code (though mixing C++ and Objective-C in the same file isn't generally supported yet; Apple's gcc supports it, but the changes haven't been merged).

One of the best things about OpenStep is that your interfaces can be completely data-driven; you nevever have to write code saying "Put a window here, put a button in it, make the button send this message to this object..." You can code that way, but it's discouraged. NeXT's InterfaceBuilder generated "nib" files which could be read in with one line to create complete networks of interdependent objects that would just do the right thing. Work on an equivalent InterfaceModeller (which generates "gmodels" since Apple never specified the nib file format) for GNUstep progresses, and gmodels aren't too difficult to generate by hand.

I think the best way to succinctly describe OpenStep is to say it is to software developers what the Macintosh is to normal users.

GNUstep is almost to the point where serious OpenStep porting and debugging can take place. (The text system is in flux right now; when that's over, I think it'll be ready.) This means that people writing new Macintosh applications will have a relatively easy time also targeting Linux; Macintosh software developers are the best in the industry when it comes to building usable, consistent interfaces to high-quality end-user applications. (Hey, I'm allowed a little egotism, aren't I?)

What's my point with all of this? It means that X isn't necessarily as entrenched as you think it is. GNUstep runs on X right now, sure, but it could also be made to run on a sane display subsystem without affecting application-level code. So the situation isn't quite as hopeless as it seems.

My prediction: If there is half as much effort put into Display GhostScript and GNUstep as there is being dumped into XFree86 and GTK and GNOME and Qt and KDE right now, X can be put on life support within two years. And there'll be a resolution-independent, device-independent, network-transparent window system with a sizable base of consistent first-tier end-user applications and a very elegant programming interface to show for it.

One thing most people seem to ignore, though, is that Linux (the OS), is defined by way more than Linux the kernel. An Amiga that uses the Linux kernel, and Amiga system libraries, Amiga shells, an Amiga GUI etc., won't look much like Linux the OS at all.

However, it will likely just be a question of adding the right libraries and binaries to let it run all Linux applications.

And this is the sweet thing about this: They can completely redefine the OS, by building something new on top of the kernel, without loosing Linux compatibility.

Which means that they can provide whatever "revolutionary" features they like, and at the same time offer access to the huge amount of existing Linux software out there.

That is something they wouldn't get with QNX - the amount of available QNX software is a lot smaller.

Contrary to QNX there is also a huge groundswell of support for Linux from third parties, and it will be a LOT easier to convince those third parties to provide Amiga applications, if they can do it in a way that let their apps run on Linux as well (maybe with some Amiga specific functionality taken out).

This can be good for Linux too, because Gateway is throwing lots of money at this, and if they start getting people to port to the Amiga, and the Amiga uses the Linux kernel, and can run Linux applications, a lot of those people are likely to make sure their applications run without the Amiga operating environment too.

In a way, I see what they are trying to do as something similar to OpenStep, which is a set of API's, that run on top of any host OS you care to port it to (ref. www.gnustep.org. It completely redefines the interface to the user, and for the developer, but the host OS is still there, and easily accessible.

If well done, it also means that if Amiga Inc. in the future should choose to support other host OS's besides Linux, any applications written to the Amiga OE APIs should instantly run in that environment.

I've got two NeXTs; a M68k Color and a 486 Cube. And I used to develop with v4.x on a Sparc. NEXT is definitely one of (if not the) best development environment I've ever used.

I - like many other former NEXTSTEP users I'm sure - am really unhappy with Apple and the Mac community corrupting NEXTSTEP as well and also lament the Mac-centric focus of Apple Enterprise...

For NEXTSTEP/OpenStep developers who feel abandoned by Apple Enterprise, definitely check out GNUStep.

Yes, it's not at all complete and requires far more development but it looks the most promising in that it's being developed in the spirit of OpenStep for eventually achieving OpenStep compliance. What's more, it's FREE SOFTWARE, covered by the GNU GPL and free from the whims and fancies of Jobs and Apple.

~AC

GNUstep

Available via http, ftp, and cvs without any
annoying licences to agree to, or registration to
sign.

Most importantly, it compiles, and most of the
test applications run successfully.

They could use some help, if you are willing
and able.

---------------------------------
"The Internet interprets censorship as damage,

If the GNUstep GNUrus can't be bothered to answer this question, why should I be bothered to look into GNUstep for using it or for developing apps? They can't even be bothered to fix their mailing-list page.

If it could be gotten to work, I'm sure it would be a worthy addition to the toolkit/environment flame^H^H^H^H^Hwars. But as it is, it seems (to this outsider) to be no more than an ineffectual quilting-bee.

Flames welcome. I'd like to learn more.

--

J Pingouin Braithwaite-Guevara, proud mwm user. I don't need no steenkin' "environment" :)

--

GNUstep is an effort to do the UI part as Free Software. GNUstep on Darwin should be very, very close to the original NeXT experience...for $0.00. Plus, the combination should be available on Alpha, Intel and other interesting platforms...not just PowerPC.

Go to the GNUstep Web Site and give us a hand! :-)

Apple could have down the Free Softare a _huge_ service by freeing the code of the Yellow Box/OpenStep which will be marginalized in MacOS X anyway. The free Unixes would have gained an open standard, technically supreme desktop which would by far surpass the reinvented wheels of KDE and Gnome. The GNUstep project is trying to accomplish this since years, but it doesn't seem as if their effort would benefit in any way from "Darwin".

If you're really interested in OO application development and tools... consider helping the GnuStep project.

Why bother with MacOS X? After all, Apple has proven to be hardly a trustworthy development partner.

We can accomplish a true (and probably superior) OpenStep compliant environment without Apple.

I am all for Gnome, but I think everyone should support also other GPL projects like GnuStep

Wouldn't that be GNUstep?

Disclaimer: I haven't had my coffee yet.

--