Slashdot Mirror


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."

54 of 166 comments (clear)

  1. macos x api by geomcbay · · Score: 3, Insightful

    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...

    1. Re:macos x api by Noer · · Score: 3, Informative

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

      --
      -- "Those who cast the votes decide nothing. Those who count the votes decide everything." -Joseph Stalin
    2. Re:macos x api by Anonymous Coward · · Score: 5, Interesting

      maybe the idea is to be ahead of the game instead of playing the typical open source catch up game.

    3. Re:macos x api by Anonymous Coward · · Score: 2, Interesting

      It looks as if 95% of the stuff that has or will ship for OS X will be using the Carbon API, not the OpenStep/Cocoa API.

      There used to be a small base of NeXT development houses, but my understanding is that most of them have folded, been bought up, or switched focus. Too bad Apple didn't buy NeXT back in 1993-4, they might have been able to save the developer base.

    4. Re:macos x api by Tachys · · Score: 2

      maybe the idea is to be ahead of the game instead of playing the typical open source catch up game.

      They are trying to what? I hope RMS and co. put a stop to this!

    5. Re:macos x api by Ian+Bicking · · Score: 2
      Not really. OpenStep/NextStep is pretty old school. Early nineties kind of thing, and I believe Objective C was designed at around the same time as C++ (early 80s?). All of these, in turn, have a very close relation to Smalltalk, which was designed in the 70s and hasn't changed dramatically since Smalltalk-80.

      Of course, that doesn't mean it's not good stuff.

    6. Re:macos x api by benedict · · Score: 2

      Well ... imagine being able to rapidly develop graphical applications that can be compiled for both Linux and Mac OS X.

      There's potential there to unify two of the most important non-Microsoft software markets.

      --
      Ben "You have your mind on computers, it seems."
    7. Re:macos x api by Noer · · Score: 2

      Filemaker Pro Server is already available for Linux, though.

      --
      -- "Those who cast the votes decide nothing. Those who count the votes decide everything." -Joseph Stalin
  2. But ... by Wordsmith · · Score: 2, Funny

    Did he say stuff that matters?

  3. GNUStep by Anonymous Coward · · Score: 3, Insightful

    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!!

    1. Re:GNUStep by Ian+Bicking · · Score: 2
      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".
      Please, expand. I remember seeing some mention of a native X rendering, but it was presented like it was just a stopgap until DGS was ready. Is Adam working on improving DGS, or somehow replacing it?
  4. Re:You should think the other way around by Anonymous Coward · · Score: 3, Informative

    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.

  5. Forget porting, how good is the API? by astrashe · · Score: 4, Flamebait

    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?

    1. Re:Forget porting, how good is the API? by Anonymous Coward · · Score: 5, Funny

      I can give you an unbiased opinion:

      NeXT API is a lot like java (well thought out OO design), but without the heavy abstraction to support the native UI underneath, and without the bytecode crap.

      MFC is like having sex while wearing 7 condoms.

      Most XWindows widget sets (the exception being KDE) are like a rusted out '83 station wagon, hed together with duct tape and bondo, carrying half a dozen pimple faced teenagers. The floors are covered with evidence of fast-food drive thru visits, and there's a funky odor. Chances are, the driver will stall it at the next stop sign, and the muffler needs replacing. The occupants, however, are glad they don't have to walk.

    2. Re:Forget porting, how good is the API? by Anonymous Coward · · Score: 2, Funny
      MFC is like having sex while wearing 7 condoms.

      ...and they are on various fingers and toes, not where they are supposed to be.

    3. Re:Forget porting, how good is the API? by jcr · · Score: 2

      >How does this graphics portion of the API compare to MFC?

      Well, in a nutshell: the AppKit is a brilliant piece of work, making the development of GUI objects easier than I've seen in any other development environment.

      The MFC is the usual shabby knock-off of MacApp (an earlier, but much poorer example of trying to apply OO principles to GUI design.)

      -jcr

      --
      The only title of honor that a tyrant can grant is "Enemy of the State."
    4. Re:Forget porting, how good is the API? by affenmann · · Score: 3, Funny


      MFC is like having sex while wearing 7 condoms.

      ...and they are on various fingers and toes, not where they are supposed to be.

      ...and all of them have small annoying holes.

    5. Re:Forget porting, how good is the API? by TheAwfulTruth · · Score: 2, Insightful

      Unbiased? Have you even used MFC? MFC is an amazingly thin wrapper around the Win32. In fact TOO thin. Rather than being a completely clean genericly useful set of classes there are conspicuous holes in the functionality of several widgets because they do nothing but wrap the lower level windows GUI functions.

      --
      Contrary to popular belief, coding is not all free blow-jobs and beer. Those things cost MONEY!
  6. the genius of the NeXT api by Anonymous Coward · · Score: 3, Insightful

    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.

  7. There are major apps... coming soon ;-) by Ffakr · · Score: 4, Interesting
    Well, I'd have to take issue with the claim that there are no native cocoa apps.

    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

    1. Re:There are major apps... coming soon ;-) by znu · · Score: 5, Informative

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

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

      --
      This space unintentionally left unblank.
    2. Re:There are major apps... coming soon ;-) by HerrNewton · · Score: 2

      Quark 5b1hit the streets a few days ago. It's a classic app: uncarbonized, not cocoa.

      --

      ----
      Am I the only one who thinks Microsoft is a misnomer? Perhaps Macrosoft would be a better fit?
    3. Re:There are major apps... coming soon ;-) by Ed+Avis · · Score: 2

      So will we see an equivalent of Wine which runs Mac OS X applications by remapping Carbon API calls to GnuStep? (I guess the answer to that one is 'if someone writes it'.)

      --
      -- Ed Avis ed@membled.com
    4. Re:There are major apps... coming soon ;-) by Matthias+Wiesmann · · Score: 2, Informative

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

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

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

  8. Question by infiniti99 · · Score: 2, Interesting

    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?

    1. Re:Question by Anonymous Coward · · Score: 2, Insightful

      The OPENSTEP API (which the OS X API is derived from) was ported to Unix, Windows NT, and OPENSTEP for Mach (NeXT's OS). This is not vaporware either.
      GNUstep is being written for Unix and NT at this time, and MacOS X is available on Macintoshes. This is nearly the cross-platform support of Qt, lacking only in the embedded market (for which you would need to be a fool to use your app unchanged anyway).
      OPENSTEP is legendary for the speed and ease of development of programs created using it. Qt is famous for resembling MFC. And besides, ObjC is a more elegant language anyway!

    2. Re:Question by droleary · · Score: 2, Insightful

      Why would I want to develop crossplatform applications with GNUStep, when I can use Qt 3.0 [trolltech.com]?

      Why use anything? If you're ga-ga for Qt, use it. If you actually want to learn about alternatives, look into GNUstep. The OpenStep API happens to have over a decade of refinements in it and is based on an outstanding OO language.

      All this using the proven C++ language.

      Heh. "Proven to suck" comes to mind. In reality, C++ is a very poor OO language; ObjC just blows it away. You can take a day out of your schedule ot learn the basic syntax additions to C and if you've got an ounce of OO skill you will immediately see the huge advantage to things like categories.

      This is not vaporware folks. Each supported platform is just that: fully supported and stable.

      Yet the page you link to has "Beta" all over it, and suggests you "Evaluate" the Mac version. Depending on your needs GNUstep might not be ready just yet, but don't go pretending that your pet toolkit is something it's not. I have SDL-based apps running on my OS X box, but where are the Qt-based apps I should be expecting from this "fully supported and stable" toolkit?

      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?

      Your argument is flawed in that it could apply to anything. If you're comfortable with Qt and uncomfortable actually trying anything new, just use Qt. Let me know when I can run your applications on my platform. I had OpenStep-based apps running on Linux in 1996, and GNUstep has only gotten better since then.

    3. Re:Question by infiniti99 · · Score: 2

      Why use anything? If you're ga-ga for Qt, use it.

      I suppose I am, and I do use it. I am not afraid to learn something new, however. I am genuinely interested in what is good about GNUStep. My post had an argumentative tone (which now carried into your post) because the article mentioned its use as a cross-platform library. Not that there can't be more than one good cross-platform library, but I think Qt is probably the best choice at the moment. With 3.0, I think we'll begin to see major application providers (like perhaps Adobe) consider using it, even if they never intend on Linux ports.

      I don't think I jumped the gun by saying Qt is viable for MacOS X development. It is already very good on Windows and X11. Trolltech has planned on 3.0 being "release quality" next month, and I don't doubt the Mac support will be very good considering their history.

      Let me know when I can run your applications on my platform

      I have good faith in Qt/Mac. If I actually had OS X, I would probably have grabbed the open beta. I do plan on porting one of my apps to OS X when I am ready.

  9. Support for MacOS X compatable API means ... by alexalexis · · Score: 2, Interesting

    ... 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?

    1. Re:Support for MacOS X compatable API means ... by TheInternet · · Score: 3, Informative

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

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

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

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

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

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

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

      - Scott

      --
      Scott Stevenson
      Tree House Ideas
    2. Re:Support for MacOS X compatable API means ... by alannon · · Score: 2

      Just a few things to clarify and correct here:

      The Carbon API is NOT a C++ API. It is purely a C API. Actually, I think it's still availible as a Pascal API, too, which was the language of choice for several years after the introduction of the Mac.

      There are several C++ frameworks availible for Carbon. Powerplant, included (with source) with Codewarrior is one, MacApp, from Apple, is another.

      The Finder is written using Powerplant, but does not take advantage of the new, more efficient event model availible in Carbon.

      The differences between the two 'styles' of Carbon applications are that one style can work in OSX and OS8/9 with a single binary file, and the latter is in the native OSX executable format (Mach-O) which allows it to be linked with unix libraries and use lower level mach kernel services, and direct Quartz API calls.

    3. Re:Support for MacOS X compatable API means ... by bnenning · · Score: 2
      Cocoa apps can currently only be written in Objective-C and Java. There is talk about resurrecting Objective-C++, though.


      More than talk, Apple has confirmed that the developer tools shipping with Mac OS X 10.1 (due Real Soon Now) will support Objective-C++. This is a big deal because you will be able to write a Cocoa front end to your existing C++ architecture, instead of using Carbon or writing a bunch of ugly ObjC to C++ bridge code.

      --
      How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
  10. IP Issues? by Anonymous Coward · · Score: 3, Interesting

    I would like to know if there are any IP issues the GNUStep have had, or will have to deal with?

  11. Objective C??? by Rimbo · · Score: 2

    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.

    1. Re:Objective C??? by Ian+Bicking · · Score: 2
      Well, Objective C is closely tied to OpenStep. It's OO in a way C++ isn't, and fast in a way Java isn't.

      It really has decent enough support. GCC supports it (from an early win for the GPL), and I imagine GCC covers more than 99% of all environments.

      If you mean developer knowledge, well... I think there's been some work to get Objective C to work well with C++ or Java in GCC (much more work in MacOS X), but I have a feeling that's more about integration, not alternate GNUStep development languages.

      Anyway, C++ people have just in the last few years found STL -- the sort of abstraction Objective C and Smalltalk has had since the very beginning. C++ just isn't doing all that good a job of catching up, probably because they aren't going to the same place. And if that's the case, well... I don't know how much of a help that would be anyway.

      Objective C isn't hard to learn, either. Easier than Java or C++.

  12. GNUStep has been in development *forever* by x+mani+x · · Score: 5, Interesting

    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.

  13. How should I put this? by jcr · · Score: 3, Insightful

    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."
    1. Re:How should I put this? by jcr · · Score: 2

      Squeak is an excellent piece of work, perhaps the epitome of what Open Source development can accomplish.

      Since you bring it up, I'll point out that Marcel Weiher has done a wonderful job of bringing Squeak up on Mac OS X. Search for "CocoaSqueak" at www.stepwise.com/softrak/

      -jcr

      --
      The only title of honor that a tyrant can grant is "Enemy of the State."
  14. It's not so much that there was a lack of support. by jcr · · Score: 2

    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."
  15. QT For Mac by Matthias+Wiesmann · · Score: 3, Informative

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

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

    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."
  17. All Carbon apps by TheInternet · · Score: 2, Informative

    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
  18. Has anyone ever noticed... by dido · · Score: 2

    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.
  19. Lineage by TheInternet · · Score: 3, Informative

    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
  20. More confusion on Carbon apps by TheInternet · · Score: 2, Interesting

    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
  21. Native apps by TheInternet · · Score: 2, Interesting

    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
  22. Have things gone backward? by thedrinuk · · Score: 2, Interesting

    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.

  23. Clarification on Cocoa vs. Carbon apps by TheInternet · · Score: 5, Informative

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

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

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

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

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

    So why write in Carbon, you ask?

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

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

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

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

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

    - Scott

    --
    Scott Stevenson
    Tree House Ideas
  24. Objective C better then C++ ? by UnknownSoldier · · Score: 2

    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

    1. Re:Objective C better then C++ ? by ReconRich · · Score: 2

      "Modern C++ Design" shows the wonderfull and elegent power of generic programming (templates.)

      C++ needs templates because it does not have a singly rooted class heirarchy. Much of the bloat in C++ programs comes from the fact that (all existing) C++ compilers generate a new class for each template instantiation. And just how much template debugging have you done anyways ? Its brutally difficult to debug template programs too. ObjC doesn't have these problems: Containers can take any NSObject as an element, and you can check types at runtime. Because there is only one implementation of a container class, there are no funky giant method names.

      "In what areas does Obj-C do better then C++" ? Is it only cleaner syntax?

      As if cleaner syntax isn't enough ;-) But seriously, ObjC is "really" object-oriented. Introspection and runtime typing are built in, so funky code generators like QT's moc and MFC's crap are unnecessary. You would think that ObjC would be less efficient than C++ because of this, but my experience says -- no, not really. ObjC programs are almost always smaller (no templates to instantiate), and as fast as C++ programs. ObjC is also "semantically" cleaner than C++. There aren't any references, operator overloading, returning objects by value, etc. that make C++ so difficult to learn and filled with pitfalls for the novice (and not-so-novice ). ObjC also clearly distinguishes between object-oriented operations, and procedural operations.

      "What can Obj-C do that C++ can't?"

      Well both are Turing-complete so can't really isn't the right thing to say. ObjC is really object-oriented, so "truly" object oriented programming is much easier in ObjC. Many people find ObjC easier to work with because its Object Model is so much simpler than C++'s. IMHO, ObjC's Object Model is more complete than C++'s also.

      -- Rich

      --
      Free your mind and your Ass will follow -- George Clinton
    2. Re:Objective C better then C++ ? by Ian+Bicking · · Score: 3, Interesting
      Introspection and runtime typing are built in, so funky code generators like QT's moc and MFC's crap are unnecessary.

      They are also unnecessary when you use templates. Templates have largely rendered macros (both C preprocessor macros and alternatives like MOC) unneccessary.

      I don't think templates can make up for introspection. Introspection allows for easy serialization and cross-network communication -- transparent distributed objects are an oft-touted feature. (admittedly, I haven't used Objective C seriously)

      Also, in my programming, collections are typically heterogeneous. With templates you'd have to have a common base class with virtual methods, and you'd no longer have much of an advantage over Objective C, while having none of the convenience.

      I think the dynamically-typed languages are more true to OO, because objects are defined only by their interfaces. Any object that implements a sufficient interface can be used in that context. You can do great things with that.

      Others might feel that message-passing is a more appropriate term for the type of OO in Objective C. However you say it, there's something there that Objective C does that C++ doesn't -- even if it might be possible under C++, people just don't.

      ObjC programs are almost always smaller (no templates to instantiate), and as fast as C++ programs.

      Are you kidding? Obj-C is notorious for being slow. As far as program size goes, I don't think you can compare the two. For one, there are few Obj-C applications of any appreciable size.

      Well, there are Objective C applications of appreciable size. There were lots of applications for NextStep -- web browsers, 3D rendering, etc. Not all of these applications are dead. They should provide significant fodder for comparison, should someone choose to do so.

      From a reductivist point of view, Objective C can be as efficient as C++ or C. With clever programming you can use dynamic typing to your advantage, because the method lookup can take the place of logic statements. I know this is very common in Smalltalk. But unlike Smalltalk (or Java), you can write Objective C with the inner loops (where performance matters) in C.

      I thought NextStep ran fairly well on the m68k workstations I used. It wasn't blindingly fast, but like I said, it was a m68k processor.

      Large systems can potentially be significantly faster in Objective C, because of the generality of the object model and the richness of the foundation library.

      "Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."

      I think Objective C has a relation to Common Lisp there (if not quite as complete -- thankfully!), and C++ is still stuck with C or Fortran -- good base libraries have been very slow in coming (though they do appear to be coming along)

  25. Portable skills by horza · · Score: 2

    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.

  26. Two questions i havce about GNUStep by mcc · · Score: 2
    1. 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.

      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?
    2. 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...
  27. Re:STEP look grows on you by Laplace · · Score: 2
    Windowmaker was my manager of choice until I discovered pwm. This windowmanager rocks for a few reasons:

    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!