Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
GNUStep GUI

Adam Fedor of GNUstep Says Stuff 166

Posted by CmdrTaco from the stuff-about-things dept.
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."
This discussion has been archived. No new comments can be posted.

Adam Fedor of GNUstep Says Stuff More

Adam Fedor of GNUstep Says Stuff

Comments Filter:

  • macos x api (Score:3, Insightful)

    by geomcbay ( 263540 ) on Wednesday September 12, 2001 @11:04PM (#2290287)
    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...

    • Re:macos x api (Score:3, Informative)

      by Noer ( 85363 )
      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.

    • Re:macos x api (Score:5, Interesting)

      by Anonymous Coward on Wednesday September 12, 2001 @11:07PM (#2290301)
      maybe the idea is to be ahead of the game instead of playing the typical open source catch up game.

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

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

    • Re:macos x api (Score:2, Interesting)

      by Anonymous Coward
      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.

    • You should think the other way around (Score:1, Insightful)

      by Anonymous Coward
      That your GNUStep applications can easily be ported to MacOS X.
    • 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. Schweet app, I'd reccomend trying it out, frggin cool.

      • 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
        • I know for a fact that they said at MacWorld the Filemaker pro they were demoing was written in Objective-C/ Cocoa.

          Maya has been demoed at at least 3 Apple Webcast events, and they've said "it fully takes advantage of OS X" The idea that it doesn't run in OS 9 makes people think cocoa.

          You're right, I can't find the word "Cocoa" in any of their documentation, but that doesn't mean it's pure carbon, you can mix Objective C/C++/Java files into the same executable in Projectbuilder.

    • Remember, Mac OS X is essentially NeXTSTEP. Since GNUStep is an implementation of NeXTSTEP/OPENSTEP, supporting the OS X API is a natural outgrowth of that. The usefulness of supporting Mac OS X isn't a matter of being practical per se, rather just a matter of being properly NeXTish.

      • Lineage (Score:3, Informative)

        by TheInternet ( 35082 )
        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
        • GNUStep apparently only attempts to address the NeXT side of the world

          > GNUStep implements the OpenStep specification (which is not NeXTStep), while maintaining compatibility with NeXTStep.

          MacOSX extensions are followed whenever possible (XML property lists, but no AppleScript,QuickTime... yet).

          GNUStep aims to be crossplatform (as OpenStep) but probably implementing most Mac OS X only stuff on all platforms will be difficult.

          - Marko

    • Re:macos x api (Score:1, Interesting)

      by Anonymous Coward
      > Its kind of cool that it supports the OS X API, but how useful is that in practice?

      Very usefull. Dev environments on linux sucks. GNUstep IB and PB are not on par with OSX ones. There are hardly any OPENSTEP or YB developers left. All the FoundationKit/AppKit developers are on OSX now, and dozen of wanabee developers discover ObjC every week.

      The OSX dev population outnumber the GNUstep one by a couple of orders of magnitude. Don't you think it is worthwhile to support OSX ?

      [of course, GNUstep should target _windows_, in addition to OSX. This would have tremendous interest. But, with the manpower they have, the GNUstep guys already did a very good job]

      Cheers,

      --fred

    • Native apps (Score:2, Interesting)

      by TheInternet ( 35082 )
      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
    • 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.
    • 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.

  • But ... (Score:2, Funny)

    by Wordsmith ( 183749 )
    Did he say stuff that matters?

  • GNUStep (Score:3, Insightful)

    by Anonymous Coward on Wednesday September 12, 2001 @11:24PM (#2290369)
    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!!
    • 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?

  • Forget porting, how good is the API? (Score:4, Flamebait)

    by astrashe ( 7452 ) on Wednesday September 12, 2001 @11:35PM (#2290408) Journal
    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?

    • Re:Forget porting, how good is the API? (Score:5, Funny)

      by Anonymous Coward on Wednesday September 12, 2001 @11:46PM (#2290445)
      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.
    • Comment removed based on user account deletion

  • the genius of the NeXT api (Score:3, Insightful)

    by Anonymous Coward on Wednesday September 12, 2001 @11:40PM (#2290426)
    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.

  • There are major apps... coming soon ;-) (Score:4, Interesting)

    by Ffakr ( 468921 ) on Wednesday September 12, 2001 @11:47PM (#2290451) Homepage
    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 [omnigroup.com] 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)

    • Re:There are major apps... coming soon ;-) (Score:5, Informative)

      by znu ( 31198 ) <znu.public@gmail.com> on Wednesday September 12, 2001 @11:56PM (#2290479)
      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.
    • Quark 5b1hit the streets a few days ago. It's a classic app: uncarbonized, not cocoa.

    • All Carbon apps (Score:2, Informative)

      by TheInternet ( 35082 )
      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
    • 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'.)

      • 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 [cjb.net]
        • 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.

  • Question (Score:2, Interesting)

    by infiniti99 ( 219973 )
    Why would I want to develop crossplatform applications with GNUStep, when I can use Qt 3.0 [trolltech.com]? 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 [trolltech.com], 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?

    • Re:Question (Score:2, Insightful)

      by Anonymous Coward
      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!

    • Re:Question (Score:2, Insightful)

      by droleary ( 47999 )

      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.

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

        • QT For Mac (Score:3, Informative)

          by Matthias Wiesmann ( 221411 )

          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.

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

          As was pointed out by another response, it has issues, as does the bulk of cross-platform work. OpenStep has been the only framework I have used that has properly abstracted from particular widgets such that native widgets can be used on different platforms, not just simulated. If you used WebObjects, you'd see how Yellow Box for Windows produces a proper looking and behaving Windows app while the same code base is leveraged for a proper OS X app. Perhaps Qt will eventually get there, too, but nobody can at this point just wave their hands and pretend they can get an application running on Linux, Windows, and a Mac that the users of every platform are happy with.

          I don't think I jumped the gun by saying Qt is viable for MacOS X development.

          You did. Hell, even Apple has jumped the gun when they say Carbon is viable for OS X development. I mean, yeah, you can get your old apps ported to OS X quicker, but as a user, it is painfully obvious which apps are Carbonized because they don't really take advantage of all OS X has to offer. Will Qt support services, spelling, transparency, toolbars, AppleScript or the Dock? If not, the user experience will drive people to your competition, who will then use GNUstep to bring a superior experience to your Linux users as well. Ouch!

    • Re: (Score:3, Insightful)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion
  • ... 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?

  • IP Issues? (Score:3, Interesting)

    by Anonymous Coward on Wednesday September 12, 2001 @11:59PM (#2290485)
    I would like to know if there are any IP issues the GNUStep have had, or will have to deal with?
    • I would like to know if there are any IP issues the GNUStep have had, or will have to deal with?

      It is legal for them to write implementations of the OpenStep/Cocoa APIs. But there are going to be walls. No Quartz or QuickTime, for example. These are considered core components of Mac OS X.

      - Scott
  • 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.
    • Because they are implementing NeXTSTEP/OPENSTEP which is intimately tied with Objective C.
    • 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++.

      • 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
        • Much of this is a matter of opinion and therefor subject to flame. It also comes up once in a while.

          One of the greatest strengths of Obj-C is it's ability to catch and forward unknown methods. You can for example do
          [[array do] doStuff:2];
          where [array do] returns an object that doesn't itself respond to any methods (except that needed to destroy it) but forwards everything called on it to all objects in the array (in this case doStuff:2).
          If an unknown method isn't caught by the object itself an exception will be raised but you can catch that as well.

          You can make calls to nil (they will be ignored) which can be quite useful as you don't have to check for failure after each call but can do it further down.

          You can add methods to classes dynamically. For instance I had the need to have a special function in all my window objects (including floating palettes). I didn't have to subclass NSWindow and NSFloating etc but instead could add an extra function to NSWindow.

          You have a general object type called id which is useful when you don't know the class of an object or it can be one of two similar classes. Which leads to the fact that if two classes has a method with the same name you can call either of them with the same call not having to know the exact class.

          If you use the Foundation (most do) you will have a reference counting garbage collector that works with all objects.

          I might have forgotten something, but I'm sure I'll be corrected in that case. :)
          • If you use the Foundation (most do) you will have a reference counting garbage collector that works with all objects

            Also worth noting is the support of boehm mark & sweep conservative garbage collector. (Which addresses many problems of ref counting such ref cycles).

            - Marko

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

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

        Not quite. You could always do smalltalk/ObjC
        style ADTs in c++. The STL involves a template
        based approach, something not found in smalltalk
        or ObjC. Templates are a compile time method
        that lets you (among other things) avoid having
        to derive from a common base object to acheive
        genericity.

    • There are two parts to the answer. The first is that any competent Java/C++ programmer can learn ObjC in a day. Those who have made this transition never want to go back. The second is that once the ObjC frameworks are complete, Java support can be added using Apple's open source Java/ObjC bridge.

  • GNUStep is UGLY (Score:1, Funny)

    by Anonymous Coward
    GNUStep is not popular for one reason. It is damn ugly. I guess when it gets aqua then it will look like the annoying over sugary OSX apps but I'm not sure that is really an improvement over Qt or GTK since you can make those look like whatever you want. The only good thing about this project is that we may see big time apps from adobe and other companies finally being ported to linux. Check out some of their "And (did I mention this already?) it looks good" (from GNUStep Info) screenshots. [gnustep.it]
    • I wouldn't call WindowMaker (or WINGS widget set , or GNUStep in general) too ugly; in fact, I was really happy when I found NeXTStep-like theme for GTK+, and I'm now trying to find Mozilla theme that would look the same. Agreed, I don't generally like the NeXTStep icon style, but at least WindowMaker is fully themable and colors can be set - same goes for the GTK+ theme.

      Personally, there's only one X widget set that I really consider to be "ugly". You guessed it, Athena. =) As long as it's "pseudo-3D" and not black and white only, it's all fine with me.

      • Personally, there's only one X widget set that I really consider to be "ugly". You guessed it, Athena. =) As long as it's "pseudo-3D" and not black and white only, it's all fine with me.

        De gustibus non disputandum, o lupine technomancer, but IMO Athena is too minimalist to really truly be ugly (though xaw3d certainly is pretty bad). To me the nadir of ugly widgets would be either QT 1.x (like Windows 95, but with a certain Lovecraftian disproportion and wrongness about its angles), or the thousand hideous white or red text on black/dark blue/dark green GTK themes out there.

        I've wanted an Athena theme for GTK (to go with my twm theme for sawfish), but to make sense it would have to be an engine theme, and I just don't have the deep GDK knowledge needed to do that. For a minimalist feel, the Flat theme for GTK is quite good; except in the scrollbars it's much like the early Mac.

    • Personally, I like the way GNUstep looks. The scrollbars, in particular, are better than any others I've used. I liked it so much that I wrote a library of Java components so I could create Java apps with that look and feel.

      Many many people enjoy using Windowmaker and feel it is the most polished and attractive window manager out there. While I use a lot of GNOME apps (with the gtkStep theme) I have no use for the GNOME desktop. Windowmaker does what I want, uses modest resources, and looks good. Give it a chance, it may well grow on you.

      • Windowmaker was my manager of choice until I discovered pwm. [students.tut.fi] 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.

  • GNUStep has been in development *forever* (Score:5, Interesting)

    by x mani x ( 21412 ) <.ac.lligcm.sc. .ta. .esahgm.> on Thursday September 13, 2001 @01:16AM (#2290668) Homepage
    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.

  • That the OpenStep logo actually looks like a stealth bomber?

  • Uh, Taco, would you mind letting us know where we might find the definition of "endorced". I've tried dictionaries, a thesaurus, and the Internet without succes...

    Pat
    • FYI, the text in quotes (and italics) in the article was written by the submitter (JgiSaw in this case). CT is not a great speller, but this one isn't his fault. By the way, what's "succes" ? ;)

  • Clarification on Cocoa vs. Carbon apps (Score:5, Informative)

    by TheInternet ( 35082 ) on Thursday September 13, 2001 @05:46AM (#2291180) Homepage Journal
    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 [apple.com], 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
    • 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.

      That's broadly correct. The foundation kit is at the 'release 1' level. To clarify, that is (roughly) the non-GUI stuff. Some might feel that's not very useful, but it is a very mature api containing a wealth of very useful classes for arrays, strings, dictionaries (hashes/associative arrays). The appkit portion (GUI, tools for applications which handle single and multiple documents, including loading and saving) is at 0.7. It works pretty well, but isn't complete.

      Beyond that there is the support for services (eg every application can get spell checking cheap) and distributed objects, which is pretty nice.

      But why use gnustep? Well, I'm a pretty lame programmer but I managed to put together a simple app using some existing Java classes in a couple of hours. Hours in which I effectively started out not knowing anything about OpenStep. Getting to a functional level of knowledge in ObjC was even quicker (something I'd never really managed in C++). If I was even half competent I could have whipped up something really impressive. I suspect Java programmers will find the transition easy. The Java classes are - erm - 'haunting familiar' ;-) Writing a front end for, say, gnupg, which could encrypt text in other apps probably isn't too hard in gnustep. And, of course, it could be ported to Mac OS X trivially.

      But I should add some caveats:

      • The c++/ObjC bridge has died (AFAIK). This is, I suspect, one of the major reasons why new (to Mac) apps are ported to Carbon.
      • Don't expect Gnustep to have Qt or Gtk widgets soon. Gnustep essentially has it's own widgets, and various 'backends' which know how to draw graphics primitives - in X or dps for example. It's not simple to add backends for high level toolkits.
      • Finally, you mentioned the lack of AppleScript/Apple events, Quicktime, and Quartz. I don't think Apple events are that important, but other two are is. It's pretty trivial to do all kinds of fancy stuff using quicktime and quartz, and many authors use it on mac os x graphics apps. That, I suspect, might prohibit many ports to Gnustep.
      • Finally, the apps that make life easy in Mac OS X (Interface Builder and Project Builder) have Gnustep equivalents (respectively Gorm and Project Centre), but they aren't complete. This isn't a major issue, but they would round the project off nicely.

      But I hope people try it. Learning Cocoa [amazon.com] isn't brilliant, but it was useful - even for GnuStep and Gorm. And I'd like to see the Mac OS X GUI infested with filthy, commie, free software. ;-)

      pldms

  • I've been working on this off and on for a time now.

    For those who're unfamiliar with the wonder of NeXTstep, this may help somewhat:

    http://members.aol.com/willadams/gnustep/

    It was originally going to be www.gnustep.net, but ran out of time to help with that.

    Also, http://members.aol.com/willadams/whatsnext/index.h tml

    There're also these things from my portfolio:
    http://members.aol.com/mistweaver/brochure-1.pdf
    http://members.aol.com/tgcovault/brochure-2.pdf

    the second file has a time-line and both have neat quotes 'bout NeXTstep.

    William
    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...
    • 1 - see ``JIGS'', Java Interface for GNUstep, a new version was just posted to www.freshmeat.net

      2 - If you want to write it, sure. The OpenStep spec though specifies DPS, and the FSF paid a fair chunk of change to get Display GhostScript written. One can access any other drawing interface one might be inclined to.

      William

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close