Slashdot Mirror

You just need to run gnustpe on darwin.
Posted with Mozilla-Mach-O

GNUstep does 'copy' OPENSTEP which is the ancestor of Mac OS X - and has by far a better UI than its successor! So please, go and support GNUstep and make our dream come true! Every single supporter is important to us!

I think that Linux desktop development should be watching Apple OSX, and use their GUI framework for something Linux could learn from.

... enter GNUstep ...

Apple getting rid of DPS was just about exclusively to do with licencing issues, which is a shame because, as you say, DPS has certain (potential) advantages in remote execution (if you implement the GUI in such a way as to allow remote execution...)

A good place to look at at the moment is GNUStep which is implementing both display APIs through a heavily hacked Ghostscript interpreter as part of its mandate to create a free implementation of the OpenStep API.

Very cool. Again, I hate saying it because, well, Adobe's recent behaviour has been less than decent, but they've done some superb things. Pity they stopped round-about 1995.

The closest thing to Cocoa on Linux is Qt,

Hasn't anyone heard of GNUStep????

Cocoa, on the other hand, is very different and is a totally new creature, and one that is proprietary, I'm afraid.

What gave you the idea that Cocoa is "totally new?" NeXTStep - the toolkit upon which Cocoa is based - was introduced in 1985.

I don't think we will see a Cocoa compatability layer for Linux - ever.

Think again - the GNUStep is precisely that.

GNUstep - it uses X11, and it's compatible with Mac OS X. Foo.

Actually, the closest thing to Cocoa on UNIX is GNUStep. It is an open source implementation of the Cocoa APIs (formerly OpenStep), and it aims to be source-compatible, so that Cocoa apps would work with a simple recompile.

This still doesn't get us any closer to Office for UNIX, because Office is written to the Carbon APIs, which is an updated version of the old Mac Toolbox.

Cocoa, on the other hand, is very different and is a totally new creature, and one that is proprietary, I'm afraid. I don't think we will see a Cocoa compatability layer for Linux - ever.

I think very few unix gui applications these days are written to be X specific. APIs like GTK, Qt, SDL, etc, aren't tied specifically to X.

Likewise, Cocoa is not tied specifically to OS X. Cocoa is just an API, like GTK or Qt, and can be implemented on different windowing systems, just like GTK and Qt.

If you need further convincing, I recommend you actually look at the GNUstep project, as mentioned earlier.

GNUstep, like Cocoa, is based on the OpenStep API. And GNUstep aims to be OS X compatible.

Most UNIX-like systems use an X11 server to draw graphics on the screen. MacOS X does not use X11; instead it uses Quartz, a Display PDF server, derived from NeXT's Display PostScript server. (The GNUstep project is working on a DPS/Quartz server running on top of X11.)

X11 and Quartz only provide basic drawing capabilities. They don't provide widgets such as menus, toolbars, scrollbars, etc. So a widget toolkit API is layered on top of the drawing functionality. In X11, common widget sets are KDE/Qt, GNOME/GTK, and Xt/Motif. Most of these APIs try to shield the programmer from having to access any of the low-level rendering calls. There are versions of Qt that can run without X11 -- the front end and back end are completely de-coupled.

MacOS X provides 2 different APIs for GUIs: Carbon and Cocoa. Cocoa is basically the NeXTSTEP/OpenSTEP API adapted for use within MacOS. It contains most of the old NeXT stuff, plus some functionality from MacOS 9. It is accessed via Objective-C. (The GNUstep folks are attempting to emulate most of Cocoa.) Carbon is basically the old MacOS 9 API in C adapted to use Quartz and the other lower-level functionality of MacOS X.

We have a roughly-Cocoa-compatible framework that does indeed run under Linux. It is called GNUstep.

The closest thing to Cocoa is GNUstep, which is compatible in most places. Get back in line.

"Cocoa" has been reimplemented to run on X in the form of GNUstep.

Cocoa is not a "distinctly Macintosh library". It is the Macintosh name for an OpenStep/NeXT library that has existed since 1985 or so.

"Oh no no no, there is no Cocoa for any other platform but my beloved fruit one!"

Hey, guys? Would you like to port all your Cocoa apps to GNU/Linux/X? What's that? It can't be done? Shut up. It can and it will.

GNUstep.

Because Cocoa is just OpenStep.

I think that fact is very much overlooked by the Mac user base, and by slashdot, because slashdot is that stupid.

if you were to port Cocoa or Carbon to the platform of choice

For the last time, GNUstep! Sheesh.

GNUstep!

As for why Apple needs Linux, lets see what Linux has that Apple didn't have before OS X. The whole slew of technologies that *nix utilizes. Preemptive multitasking, protected memory, SMP. All of which are VERY important.

Yes, these are new with Mac OS X but since when did Linux have anything to do with it? Mac OS X is based on the Mach microkernel and BSD. You seem to be making the assumption that Unix==Linux.

A million and one Linux apps which are easily portable to darwin.

Yes, all command line or X windows based. The CLI ones are obviously important and useful to Mac OS X. The X Windows ones are mostly useless. Mac OS X doesn't have an X server. Sure, you can download one but, at > 40MB, how many will? I have one but I'm not average.

By the way, and I know you didn't say this, a lot of people seem to think that Mac OS X is going to help bring more apps to Linux. How? CLI possibly but I think that transfer is going to go in the other direction. GUI apps? Impossible. It'd be no easier than porting them from Windows. The GUI APIs are entirely different. If you want Mac OS X programs (Cocoa ones anyway) on Linux, go help out with GNUStep.

After saying all that, Linux and Mac OS X do have things to learn from each other. You just gave some bad examples. Linux could learn a lot from Aqua and Apple could learn a lot from the power of the open source model.

Maybe Linux isn't supposed to end up as a desktop OS and maybe Mac OS X isn't meant to be a server OS. Maybe I'm wrong. Maybe we should take a lesson from biology: diversity is good. Monopolies run by ANY company or group are bad. I don't want everyone to be using the same OS as me, Linux, Windows or Mac OS X, the potential for virus and worm plagues is too high. Not to mention the stagnation that usually follows. I see the ideal as lots of standards: GUI API standards, networking standards, etc, etc. Then you'd have a very heterogeneous mix that is still largely compatible with each other

No one can create or copy Mac OS X, you say? Take a look at GNUstep - an almost 100% Mac OS X compatible development framework, straight from the Free Software Foundation itself.

I really hate how people fail to see that Mac OS X is just OpenStep. People are more eager to draw the connection to BSD than to NeXT. I think that's just plain wrong, and anyone who looks at the system libraries should agree with me.

You're missing the most important part -- Mac OS X software is not neccessarily going to be any more portable to UNIX than Windows software is, because 99.9% of commercial developers will target the proprietary APIs like Cocoa.

No, dude. Cocoa is pretty much just a new name for the OpenStep API, with a bit added. GNUStep is working on writing a fully OpenStep-compliant environment to run on *nix and Windows, and is coming along nicely. When it's more complete, Cocoa applications will be very portable to other operating systems.

Of course, that isn't to say I'd abandon this beautiful OS and go back to Linux, but hey :)

2. Neither Linux (currently technically incapable) or OS X (incompatible hardware) are in a position to challenge MS for the commodity desktop. This situation is not likely to change any time soon.

Perhaps you should preface that with "my opinion is..." I believe many people are having great success with linux on the desktop. Unless, of course, you have some actual, logical proof to the contrary.

OS X will /never/ be ported to x86.

Darwin (core of OS X) already runs on x86. Perhaps you meant Aqua.

Firstly, Apple has no interest in alienating MORE developers with yet another giant architectural switch-over.

GNUStep is the full OpenStep API, which forms the core of Cocoa, and runs on Linux, Darwin, Solaris and a bunch of other OS's which I'll leave you to look into if you're so inclined. The GNUStep developers have even expressed a desire to track Apple's recent updates to OpenStep(which make up Cocoa). That takes care of multiple platform compatibility.

Furthermore, you don't seem to realize that the Cocoa/OpenStep API's are themselves cross-platform->easy for Apple to port and since platform-independence is a major factor in Cocoa/OpenStep, developers wouldn't have to do a damn thing except recompile to port their apps over to any architecture that currently hosts OpenStep. Perhaps you meant a hardware switch-over forcing people to buy new machines?

And secondly, Apple makes the lion's share of their money from HARDWARE sales.

You could argue that increased compatibility with existing x86 software would bring Apple more machine sales. I sold computers for about two years, and Windows compatibility was a big reason people weren't buying the Apple machines I was trying to sell. Either because they already owned apps which wouldn't run, or because they wouldn't have the availability and selection of the Windows software world. If Apple managed OS 8 and 9 compatibility through Classic and Carbon, they could certainly perform a similar feat for OS X on x86.

Not only would that bring them more software, it would give them cheaper hardware and parts to work with, and they wouldn't have to worry about hyping "The PPC is 2x as fast as an equally clocked x86 chip!". Additionaly, they'd have the coolest looking boxes and best built/bundled hardware of any x86 manufacturer anywhere. Any computer stores would gladly accept Apple machines, compared to now where most wouldn't touch them with a pole. If executed properly, I definitely think Apple could succeed in the x86 world.

What kind of shell does this "console" for Darwin/BSD have? Does it come with bash? Does it come with many of the standard Unix tools like top, vi, etc... Does the directory structure look fairly close to Unix? Do the Mac user apps really go into /usr like we're used to?

top, vi etc are all there. /usr/bin is where CLI programs go. MacOSX GUI programs go into /Applications. This is so that if you don't want to use a command line, you don't see any CLI apps (/usr is invisible to the GUI by default). A Terminal window sees all though.

There is no need for the quotes around "console". It is not some lame DOS ripoff that Apple put there for marketing purposes. Open a term window and you'd be hard pressed to tell it apart from FreeBSD except for directories like /Applications being there.

And this toolkit on the extra CD... is that the Cocoa tools? Is it somewhat comparable to how Qt/GTK is worked with?

Is almost seems like OSX is "open" at the Darwin/BSD level, but the "closed/restricted" part is the GUI level above. You can work with the Cocoa tools to build apps, but unlike Qt/GTK, you can never have open access to much of what's going on in the UI layer. Does that seem about a fair description?

Yes, you can't change the source. Apple is a NASDAQ company and must make money. They have to keep some things in-house. The Cocoa environment is EXTREMELY good though and by subclassing etc you can override a lot of defaults, not that it's usually necessary though. Apple did a good job the first time. If you want to see how some things are implemented, check out GNUStep, an open source implementation of Cocoa for Linux.

Good, object orientated frameworks mean that you don't have to see the source to have flexibility. Check out the Cocoa docs.

I think the fundamental problem here is related to yesterday's story about new user interfaces [slashdot.org]. It's a problem of how and where storing our files.

You could also trace it back to the hierarchical database article, which is when I started making a lot of posts on the subject. It seems there is finally a lot of interest being generated about this sort of thing.

I have no idea how to implement such a beast. I'm thinking about a RDBMS with indices on 'filetype' and 'application', but I would love to see something much more flexible. All pictures should be accessible under ~/pictures and subdirectories, all files relating to my vacation last year in ~/summer2000. Files relating to both should be in ~/pictures/summer2000 _and_ ~/summer2000/pictures.

This is exactly the sort of thing I'm doing with my Meta Object Manager (MOM) software called Mary. Metadata in the form of attributes and values is associated with each file/object and you can do a query (both textually and graphically) on that metadata. For simple paths like you describe, it is a value query irrespective of a particular attribute, but there is support for a more structured "path" (I actually call it a "focus" as it restricts your focus to a subset of the objects on the system) like /type=picture/location=Hawaii/year=2000. Because the focus items are metadata attributes, order is not significant. With such a system, there are no directories or symbolic links; it's all dynamically structured based on what your metadata focus is at any particular time.

Mary is just in the alpha stages at this point, but it already works well on the command line for the type of things you describe and I'm using it myself to manage nearly 350,000 objects that have been flowing through my system. I'm not exactly sure when it'll be ready for public consumption, and it'll require a GNUstep port to get working on Linux (I'm doing development on Mac OS X) systems. I was hoping year end, but I don't think I'll have the time. Summer 2002 has a nice ring to it, though. :-)

Actually, I think Office X is a Carbonized app, making it near impossible, even if you had the code, to make it run, as is, on Linux or BSD. Cocoa and Carbon are API layers, not widget sets, with Carbon being the "cleaned up" version of the Classic Macintosh API that will run without the emulation layer on OS X.

Quartz is the display engine built around Display PDF, a superset of Display Postscript. Considering that Display Ghostscript is basically done, I don't know if the GNUStep guys are thinking about expanding it to encompass the new API's and functions exposed through Display PDF.

So my theory is no way, no day, not anytime soon. And really, except for Access, what is there that OpenOffice doesn't offer you that MS Office might?

Gnustep? I've been pretty happy with Gnome so far, but I must say I'm getting annoyed with Ximian's shenanigans. I understand they need to turn a profit and because of this require some sort of business model. However, picking apart the various bug-you-for-money "features" of ximian Gnome -- such as doorman -- in order to support a couple hundred gnome desktops, combined with the outrageously poor documentation in Gnome, makes for some serious headaches. Enough for me to simply dump Ximian Gnome when we migrate to RH7.2.

All that said, I really wish RMS would help the GnuStep project with more funds and programming staff rather than trying to push the Gnome group around. Gnome is doing fine on it's own and doesn't need the guidance or help. It's Miguel's baby, let him manage the project. GnuStep was around long before Gnome and I believe was at one point an official part of the GNU project. I honestly think GnuStep offers better potential as a free desktop environment than either KDE or Gnome, and GnuStep seems to be really coming along lately. Never mind that a free Display Postscript X Server extension in XFree86 would be of great benefit to us all.

JMO,
--Maynard

We have OSX on Linux. We have GNUStep, with them, the apps of OSX will be ported to Linux without effort, but there are a little number of developers.

I think that the people must focus on GNUStep instead GNOME or KDE, their API is better, (NeXTStep) and the object model is for real, not "oriented" with patches (if you know smalltalk, you know what i mean).

Is very natural to do Distributed Objects or Embedabble components in GNUStep, without any addition, is very very easy.

Give them a look.

I was going to mod this down when I read the bashing. Then, I was going to mod it up when you said the magic word, "simple". Then I decided to just reply. There's more going on here than GNOME and KDE. Check out GNUstep.

Apple's new APIs are really interesting once you get into them. There is a port of Cocoa to linux called GNUStep. If you want mac applications on linux, help them out.

Check out two links: GNUstep and WindowMaker. These two, combined, are producing something far better than a lame Windoze clone: a NeXTSTEP clone!

What about a true dynamic runtime? In C++, you can't call a method when you don't have a pointer to it inside the vtable (some folks even confuse them with functions because of that fact). That gets you a speedy app, but many things (like EOF) are just not possible.

Check out gnustep.org, or more specifically their page about Display Ghostscript.

Check out gnustep.org, or more specifically their page about Display Ghostscript.

Sun made new one (Java)

Microsoft too (c$ oups, sorry c#)

Why not using existing ones like Objective-C which is, like C++, based on C with OO but, unlike C++, have real dynamic capacities.

There's multiple implementation (gcc support it, for exemple). It's possible to make an interpretor if you dislike compilation (NeXT did this kind of thing for WebObjects).

It has nothing to do with Java having networking built in mind, it's just the java.net libraries.

If it's important to you, build your next app with a good base library. OOP can be a royal pain unless if you have a good framework to build on. C++ doesn't have one (just model objects & stuff). Java has a fairly crappy library that's supposed to scale from applets to servers.

Something (crappy libs) compared to nothing (C++) tends to win.

Personally, I find GNUstep and Cocoa to be much more useful and productive.

What would you say if asked to justify the idea that creating two different .NET implementations is a more valid use of manpower/volunteer time than devoting that same time to the Linux and Windows versions of GNUStep, with the goal of getting them to the point where GNUStep can be presented to corporations as something to develop for one platform & compile for three OSes? The head start given by the work already done on the Foundation would be enough that if the Community was to try to help GNUStep, they would probably have the time to add support for the java and python programming languages. (Cocoa supports java already.)

Is the c#/.net framework really any better than gnustep would be with a slightly updated objective c or java?*

Why accept Microsoft's conception of the universe and bring it to linux when you can bring your own conception of the universe to Windows with about as much work?

And do you think that Sun will recognize the two or three tiny valid threats in .NET -- a VM that is designed to be compiled to from any programming language, things being seen as slightly more "open", a thought-out system for meshing different object-oriented programming languages-- and move to fix these things?

What would it take to push apple into making NeXTStep a truly cross-platform development environment again? If they did so, would anyone actually use it? (i.e. which is greater: the dirty feeling coming from using an MS platform, or the dirty feeling coming from using an apple (NeXT) platform.) Or is .NET better than *Step/Cocoa anyway?

Will apple or sun actually move to ensure that they remain with products that are better than microsofts', or will they just assume .NET is vapourware and will fail, and pretend it isn't there?

In the upcoming war, which product is X and which is NeWS? Is that an appropriate anology? Are there any third alternatives outside of java/.NET?

What would it take to get the universe to a point where the API and VM for the next generation of operating systems (as well as a system, such as c# offers, where objects can be inherhited across operating systems-- CORBA generation 2, maybe, except actually usable?) is determined by a truly open, inclusive board of experts representing the entire industry, along the lines of an idealized version of the w3c or opengl?

What would the software industry be like *right now* if at the time that Sun began to release Java, they had had the money, resources and ability to get products installed on consumers computers' "by default" that microsoft has right now? I.E., how much better would java be if Sun had been able to rapidly mature it the way Microsoft will be able to rapidly mature .NET? Or is java just inherently doomed because it was the first product of its type, and microsoft is able to learn from Sun's mistakes with 20/20 hindsight?

Is microsoft doomed because rather than attempting foresight, they're just trying to replicate java, slap on an authentication mechanism, with little attempt to do more than fix sun's mistakes?

What the hell is going on?
I'm going to go curl up now.

(please do not respond to the following. i am just trying to explain where i am coming from in wondering these things:)
*(I would honestly like to know the answer to that one. I have used Cocoa and love it to the point i would make my OS choice based on it solely. I haven't looked at C#/.NET because i don't trust MS and believe that if they are given power, any kind of power, they will abuse it. This is nothing more than internal bias and i am not attempting to justify it as "true", or start a discussion on that subject. I just want answers to the questions above. And i am secure, because after programming some Cocoa i know that NeXT will never die the way that the Amiga will never die.) .. here goes nothing.. *submit*

No.

Maybe I'm missing something here but how is MSOffice going to be on OSX if it's based on BSD and Microsoft's apparently not developing Office tools for UNIX.

As I've heard, it will be offered in both Carbon (legacy MacCrap [tm] API) and Cocoa (spiffy-keen NeXT OO API) versions. Of course, the Cocoa version might compile with some tweaking under GNUstep. But I'm not expecting MS to do something like that. Hell, we can't even get *OMNI* to do it with OmniWeb.

Cocoa (the Object Oriented frameworks formerly known as OpenStep) is much more than UI. It's split into the Application Kit (a GUI framework) and the Foundation Kit (non graphical objects for common data and networking operations). It is an openly published standard and there is a GPL'd implementation called GNUstep that runs under various Unices (*BSD, Linux, Solaris...) and partially under Windows (someone needs to write a backend for the GUI stuff).

It seems to be missing much of the basic funtionality of X11, i.e. network tranceparency.

Cocoa has nothing to do with this--it's just an API. All display stuff (including network transparency) is handled by the Window Server. It was present in the good old days of OPENSTEP/Mach and was present for a while in MOSXS. Apple removed it...go complain to them to bring it back.

If Apple wants to pay for free software to be ported to their proprietary interface, that's their business.

Apple doesn't give a damn. Really, they don't care.

I just don't see how it benifits free software to port to OSX.

Do you oppose the use of GPL'd software in Windows? What about the poor users? Remember, the idea is to make great software available to others--regardless of their platform of choice.

It might be useful to build a Cocoa wrapper for X11. That would enable code written for OSX to run on Real Linux/Unix.

Again, try GNUstep. Better yet, go learn Objective C and help write some good Steppin' applications.

Cocoa (the Object Oriented frameworks formerly known as OpenStep) is much more than UI. It's split into the Application Kit (a GUI framework) and the Foundation Kit (non graphical objects for common data and networking operations). It is an openly published standard and there is a GPL'd implementation called GNUstep that runs under various Unices (*BSD, Linux, Solaris...) and partially under Windows (someone needs to write a backend for the GUI stuff).

It seems to be missing much of the basic funtionality of X11, i.e. network tranceparency.

Cocoa has nothing to do with this--it's just an API. All display stuff (including network transparency) is handled by the Window Server. It was present in the good old days of OPENSTEP/Mach and was present for a while in MOSXS. Apple removed it...go complain to them to bring it back.

If Apple wants to pay for free software to be ported to their proprietary interface, that's their business.

Apple doesn't give a damn. Really, they don't care.

I just don't see how it benifits free software to port to OSX.

Do you oppose the use of GPL'd software in Windows? What about the poor users? Remember, the idea is to make great software available to others--regardless of their platform of choice.

It might be useful to build a Cocoa wrapper for X11. That would enable code written for OSX to run on Real Linux/Unix.

Again, try GNUstep. Better yet, go learn Objective C and help write some good Steppin' applications.

I don't think *any* free software should be ported to Apple's user interface API (Cocoa?)

Cocoa is one of the sets of APIs available to developers. Others are Carbon, Java and raw BSD.

It seems to be missing much of the basic funtionality of X11

Oh, the irony of this statement.

i.e. network tranceparency.

Quartz (the window server/graphics API) does not, at this time, have remote display capabilities. Considering everything that had to be done for the first release of Mac OS X, and taking the target audience into account, it's not surprising that this wasn't a high priority.

But that's about where it ends. Quartz is quite full of functionality.

If Apple wants to pay for free software to be ported to their proprietary interface, that's their business. Expecting the comunity to do it for them is unreasonable.

Another poster addressed this, but just to reiterate -- Apple probably doesn't care all that much if OpenOffice runs on Mac OS X. I mean, they might promote it at the Mac OS X site, but they're not in desperate need of another office suite. MS Office is the biggie, and Apple makes the alternative -- AppleWorks. These are both built FOR the Mac. They're probably going to provide much a better end user experience than Unix-dervied OpenOffice ever will. The idea is to do a for users/by users port of OpenOffice so there's a free alternative.

I just don't see how it benifits free software to port to OSX.

So more poeple can run it?

It might be useful to build a Cocoa wrapper for X11. That would enable code written for OSX to run on Real Linux/Unix.

You probably want GNUStep, but it's not exactly finished.

- Scott
--
Scott Stevenson
WildTofu

There is one thing that bothers me about this whole mess. (Yes, I have read the flamewar. I am on the gnome-components-list where it started. After being assaulted by almost 100 emails of ever increasing rage on Saturday, I feel qualified to call this a royal mess.) That thing is the fact that GNOME 2 is already about a year overdue. The original release date was supposed to be sometime near the release of KDE 2. GNOME has been delayed several times. Implementing a new process and starting up commitee meetings to discuss features will only slow the project more. For example, there is supposed to be an API freeze soon. This is what Martin B. was working so hard to meet.

I am just wondering how much this meltdown is going to set the project back.

It is not people flaming each other that will kill GNOME. It is the constant setbacks. I am an avid user of GNOME. I still have GNOME 1.2.x on my SuSE 7.1 box though. Looking at the progress of KDE development it is easy to see myself switching to it. Hell, the progress of GNUstep is happening at a faster rate than GNOME right now. There are too many other desktop projects out there for GNOME to survive many setbacks of this nature. There are KDE, GNUstep, XFCE (used by Alan Cox), FoxDesktop, and ROX Desktop just to name a few. I have a feeling that due to issuses like this GNOME is going to start loosing its userbase.

Falling into obscurity I think would be worse for them than a few developers quitting because of holes in their flame-retardant underwear.

As I mentioned elsewhere in this thread, there is no such thing as an "Aqua application". You would use the portable Cocoa frameworks to write the application and then compile it on MOSX. Or other operating systems with GNUstep.

There is no such thing as "writing an application for Aqua". Aqua is just a realtime rendering engine.

or even a Cocoa version.

There ya go. Remember, Cocoa (the two main high-level frameworks) is an elegant and portable (and there's a GNU implementation) API. Aqua is a separate drawing engine.

Sun Microsystems' James Gosling created a displayed PostScript as the basis for NeWS around 1985. This implementation was never particularly Adobe/Apple-PostScript compatible and was only licensed from Adobe shortly before Sun abandoned it. However it was the first use of PostScript for a windowing system.

NeXT then licensed & underwrote development of PostScript into Display PostScript (no direct relation to displayed PostScript.) This was the basis for NeXT's NextStep interface and lives on today in GNUstep.

Apple has recently independantly implemented the PostScript-derived PDF from public specifications for it's Quartz rendering layer in it's recently released MacOS X.

Thus you've a single well known, well documented language that's been used for three independant windowing systems over the course of 15 years, two of them independant of the language's licensors. Add that to it's direct application to printing and it's a pretty powerful argument for further consideration as an X-Window alternative/successor.

cocoa programs are probably harder.

... Unless you use GNUStep, in which case it's a breeze. Since the GNU version of Interface Builder isn't yet decent, there are tools available to port your MacOS X NIBs to gmodel files and your makefiles to GNUStep makefiles.

You can see out the current state of GNUStep on their progress page. As of April, the GNUStep base is finished. 1.0. Complete. The GUI's pretty damn fine too.

You're right about Carbon apps though. Unless someone ports Carbon to unices other than Mac OS X, it's not going to happen. And I can tell you right now, it's not going to happen. Your best bet for portable apps is Cocoa/GNUStep, which works amazingly well.

cocoa programs are probably harder.

... Unless you use GNUStep, in which case it's a breeze. Since the GNU version of Interface Builder isn't yet decent, there are tools available to port your MacOS X NIBs to gmodel files and your makefiles to GNUStep makefiles.

You can see out the current state of GNUStep on their progress page. As of April, the GNUStep base is finished. 1.0. Complete. The GUI's pretty damn fine too.

You're right about Carbon apps though. Unless someone ports Carbon to unices other than Mac OS X, it's not going to happen. And I can tell you right now, it's not going to happen. Your best bet for portable apps is Cocoa/GNUStep, which works amazingly well.

cocoa programs are probably harder.

... Unless you use GNUStep, in which case it's a breeze. Since the GNU version of Interface Builder isn't yet decent, there are tools available to port your MacOS X NIBs to gmodel files and your makefiles to GNUStep makefiles.

You can see out the current state of GNUStep on their progress page. As of April, the GNUStep base is finished. 1.0. Complete. The GUI's pretty damn fine too.

You're right about Carbon apps though. Unless someone ports Carbon to unices other than Mac OS X, it's not going to happen. And I can tell you right now, it's not going to happen. Your best bet for portable apps is Cocoa/GNUStep, which works amazingly well.

Back in early 2000, when I alarmedly learned that Eazel was developing "just" a file manager, I faxed Bud Tribble about the possibility of developing/using something like GNUstep instead because it had roots with NeXTSTEP and MOSX. At that time, it seemed like one could tap into the marketable aspect of similar API's. Apple had just announced the layering of MOSX with Darwin; it seemed like an interesting thing, particularly because Tribble was from NeXT and Andy et al. were from 0ld sk00l Apple.

Tribble responded intelligently, which showed me that, although the idea was (of course) a pipedream, he actually had heard of the technologies enough to talk about it. For me, I think, that's the difference in my mind between Eazel and the normal dot-com carnage - the Eazelites are geeks who got caught up in the 99-00 goldrush and were burned. We can fault them severely for that, but I think that, collectively in the community, there seems to be a very silent sense of respect for what they tried to do.

One of my biggest gripes of C++ is that when you call a method, you're actually executing a function. OK, in any language this is true, but a C++ method isn't any more flexible than a function.

In Objective-C, which is a dynamic OO language (not strongly staticly typed like C++), objects respond to messages (implemented by methods). Methods have unique signatures. For example,

- (void) setSize:(NSSize)size;

This is a message that any object can respond to if it supports "settting a size." NSSize is a two-dimension size thing (x,y). If you had an object that represented a file, it might respond to

- (void) setFileSize:(unsigned long) inBytes;

But it should not respond to:

- (void) setSize:(unsigned long) size;

The compiler will give you a warning if you do, saying that the receiving object may only implement sizeSize:(NSSize). But code will execute fine, as long as you know that the types are fine. The compiler will also check this for you if you give it the types of the objects (which you pretty much always do).

Objects are designed to talk to other objects. If you stick to a set of rules (the OpenStep/GNUstep frameworks define a great set of ground rules), you can have objects communicate with other objects easily, and not have your code bug-ridden.

Better yet, in Objective-C, you can define optional behaviour.

if ([monitoringObject respondsToSelector(@selector(sizeChanged:ofObject: )))
[monitoringObject sizeChanged:foobar ofObject:sizeableObject];
else
;//monitoringObject doesn't need this info.

(a note to the confused; when you send a message, the runtime "selects" a method to respond to it. That's why you see "selector" up there.)

Not the greatest example of why you would want it, but the important distinction between Obj-C and C++/Java is that you are thinking about how objects communicate, as opposed to how object types work with other types.

A truly modular lanuage would be great for a Open Source language

dude.... http://gnustep.org. We'd love your help.

ok, we're not building a language, but of modularity is what you want, help us complete this stuff :)

"Second, open source contributors are going to be less likely to develop software for MacOS X if they're going to be expected to clear all of their development plans with Apple's legal department first. It's hard to be creative and "Think Different" under these kinds of restrictions."

Apple's legal actions should not at all be interpreted as a sign of anti-Open Source activity. Apple has a history of legal actions against UI "themes" projects - all until now have been proprietary. It is pursuing the themes nature of this project, and not at all the Open Source aspect of it.

On the other hand, Apple has allowed all sorts of porting of its APSL software to other platforms, it has allowed the GNUStep project to continue for ages, all without any incident.

In truth, this is probably the trickery of the actual theme project maintainers - I wouldn't be surprised if the project leaders were behind the proprietary theme packages. They're attempting to wedge the Open Source community in between them and Apple Legal.

As you may recall, Lars Ulrich said the exact same thing with Napster - Napster made it seem like Metallica was going after its fans, when in reality the company wasn't going after the fans at all.

Apple Legal is going after the themes project - this has nothing to do with Open Source.

I also have some slick cartograms, which make even boring economic/demographic data seem cool.

andy a.