What is Digg?59 Comments
- phisquare, on 10/12/2007, -8/+36Chocolates. Lots and lots of chocolates.
- inactive, on 10/12/2007, -4/+31Finally, iTunes for Windows! ...oh wait
- chucker, on 10/12/2007, -1/+27Of course, iTunes isn't written in Cocoa… ;-)
- mrteacup, on 10/12/2007, -1/+26It means that developers could potentially write apps that work on OS X and Windows. Or port OS X apps to windows.
- w0rd, on 10/12/2007, -1/+23You rang?
Why does everyone always ask for me? Sometimes I feel as persecuted as titlesaysitall. - codyman, on 10/12/2007, -1/+15So.. what does this exactly mean in terms of what we can expect from this....
- Chewie67, on 10/12/2007, -0/+13Exactly. Does this mean we can write applications in Cocoa on Windows, then compile them for OSX?
- SeBBBe, on 10/12/2007, -12/+23The Windows version of iTunes sucks anyway so yeah, a more direct port of the OS X version would be great.
- clord, on 10/12/2007, -1/+11Are you kidding? objective c is a lot like what c++ should have been. I'm the first one to step up and espouse the advantages of modern libraries like STL or Boost, but objective-c accomplishes much more with much less changes to the C language.
Sometimes when coding in ObjC, i miss the how C++ structs and classes are the same... or operator overloading. but these are kludges added on to make c++ feel more natural. - NSResponder, on 10/12/2007, -0/+9According to the project page:
Some things not implemented at all, or barely working
AppleScript classes
Key/value coding
Predicates
NSDecimal*
NSHTTP*
NSURL*
NSXML*
NSIndex*
NSPort*
Controllers
Most bitmap/vector image reps
NSOpenGL*
spelling
printing
newer controls, segmented controls
Distributed Objects
NSStreams
Seems like there's a lot less here than GNUStep has.
-jcr - drlha, on 10/12/2007, -1/+10iTunes is a Carbon app, so wouldn't work on this even if they fully implemented the Cocoa API.
- astrosmash, on 10/12/2007, -1/+10> If only objective C wasn't the bastard child of smalltalk and straight C.
That's a very interesting point of view.
You'll hear people say that a certain language isn't a "real" object oriented language, or isn't a "pure" object oriented language. Well, Smalltalk is *the* pure object-oriented language those people are comparing to.
Smalltalk was this "pure" OO language from the 1980's that required this big, expensive virtual machine and tons of memory. As a result, it was way too slow and resource intensive for the machines of the day. A big, slow virtual machine. Where have you heard that before?
So in the late 80's people tried to re-implement the best ideas from Smalltalk into a solution that would run acceptably on the machines of the day. This is where C++, Objective C, and Microsoft's COM came from. They are all compromises between the pure OO of Smalltalk and the performance realities of basic PCs.
C++ is the least like Smalltalk, having no dynamic binding capabilities. But it had the best performance and was the most "C"-like and as a result because the most popular programming language of the 90's
You cannot deny the success of Microsoft's COM, which brings dynamic binding to various languages, including C and C++, and is the basis behind virtually all of their technology from the 90s.
But Objective C was the most like Smalltalk. Dynamic binding by default, built right into the language. It's essentially COM without the cruft. There were performance concerns, but nothing like the problems the Smalltalk virtual machine had. But what's most interesting is that the original Java designers were big Objective-C fans, and as such their experience with Obj-C formed the basis behind much of the Java language, which in turn formed the basis behind Microsoft's .NET platform and C# language.
Fast forward to today, Java and .NET are on the way up while C++ and COM are dying. Yet, between Java, .NET, and Objective-C, only one of those languages has been and continues to be used for writing complex, consumer-oriented GUI applications. - astrosmash, on 10/12/2007, -1/+9I've always felt (long before OS X) that if the open source and Linux community had put their weight behind GNUStep rather than the crap that is Gnome and KDE, the Linux desktop would be a much more interesting and viable alternative to the mainstream commercial operating systems than it ended up being. It's kind of sad, actually. In the 90s it was all there for the taking, and no one (other than Apple) ran with it.
I'm thankful that at least someone ran with it! - inactive, on 10/12/2007, -4/+11Yeah, because if there's one thing that Windows PCs lack that Macs have an abundance of, it's software. So now a lot of that wonderful Apple-only software will finally make it to the PC and end this terrible decades-old drought.
:)
Just kidding, guys. I love Mac OSX. Heh. - EruLabs, on 10/12/2007, -1/+7Yes, on the powerPC - on my core duo mac book Itunes it still a horribly slow application.
P.s. Itunes isnt written in Cocoa - The reason this rocks is because Cocoa is a fairly entertaining and fun language (IMHO), and the easier it is for small developers and hobbiests to port their code around, the more awesome smalltime (and open-source) applications we will see on both platforms, and thats good for everyone. - camkerr, on 10/12/2007, -2/+6I think its something like...with some minor code tweaks (just like Apple did to run their cocoa PPC apps on Intel Macs natively) you could see Cocoa Mac apps running on Windows machines? But don't expect Apple to come out with a Windows version of iLife or anything like that.
- tyrione, on 10/12/2007, -0/+4Since the creator of Gorm.app (JCR) has responded I'm trying to wonder how is it that the work wasn't put to GNUstep first which would have accelerated its complete implementation of the Openstep API.
And to the idiot who complains about ObjC Runtime being slow (I took worked at Apple and NeXT) all I can say is, ``you're full of ****.'' - raynevandunem, on 10/12/2007, -1/+4I'm wondering if this could be the start of a cross-platform Cocoa Runtime Environment.
I mean, .NET and Mono has C#.
Java has....uh, Java.
Cocoa has Objective-C.
Plus, with experimentation outside of Apple's realm, Cocoa could be taken further in its capabilities.
For instance, Apple hasn't natively implemented SVG or XUL into their Cocoa. There are third parties which have:
SVG
http://www.uncommonplace.com/xvg/
http://toxicsoftware.com/blog/pettysvg/
XUL
http://www.gnustep.it/Renaissance/index.html
But the only way that they'll gain any acceptance into a popular implementation of Cocoa is most likely outside of Apple, IMO. - skellener, on 10/12/2007, -1/+4"It means that developers could potentially write apps that work on OS X and Windows. Or port OS X apps
to windows."
People still use Windows? Really? - webmaniac, on 10/12/2007, -0/+3Well, like the creator of Cocotron said on his weblog, it was a private project at first. Probably to port some openstep application to the windows platform for a client or something. The author probably wanted to keep the sources of the application private, so using GNUStep (GPL) was not an option. Releasing Cocotron using the MIT licence makes sure the original application can be kept closed source.
- r3zonance, on 10/12/2007, -0/+3"Or port OS X apps to windows."
Not really, cos there will be none of the new Core APIs (CoreAudio, CoreImage, CoreVideo), Quartz will be completely missing, and basically anything else which wasn't in OpenStep, which is a hell-of-alot. - cstruhar, on 10/12/2007, -2/+5"So.. what does this exactly mean in terms of what we can expect from this...."
Realistically, not much. It means developers on OSX using XCode should be able to compile applications for Windows with relative ease which were written in Cocoa (which prior to now was practically OSX only), but most applications that exist on OSX already exist in some form on Windows anyway. I imagine most major developers (such as Apple) won't use this anyhow, at least any time in the near future. It is a very cool project though, could open the door for more cross-platform capabilities later on. I hope they continue working on it and succeed. - SnakeO, on 10/12/2007, -3/+6It's not that the programs don't exist on windows already... It's that now they can have a ***** decent interface
- webmaniac, on 10/12/2007, -0/+3"I'm wondering if this could be the start of a cross-platform Cocoa Runtime Environment."
Just a small correction, it's not a Cocoa Runtime, but it's an Objective-C runtime. Cocoa is the framework, a collection of classes that make programming in Objective-C so easy.
"Cocoa has Objective-C"
The other way around: Objective-c has Cocoa
BTW, thanks for the links to the svg stuff. - terminalpariah, on 10/12/2007, -1/+4So when does Adium for Windows hit? I need it!
- inactive, on 10/12/2007, -0/+2Any signs of a new Finder in 10.5? Not yet, as it seems...
- SeBBBe, on 10/12/2007, -3/+5Might add that I'm mainly a Windows user, mostly because I game a lot, so a PC was a more sensible choice to me. I traded a better OS and better design for more power (also use Linux from time to time so I'm not completely stuck with Windows). Simple as that.
But I did an unbiased consideration and I can - just as unbiased - say that the OS X version of iTunes is much better than the Windows version. - NSResponder, on 10/12/2007, -0/+2I'm not the creator of Gorm. What gave you that impression?
-jcr - swordphish, on 10/12/2007, -0/+2Wow. I never knew IBM had anything to do with OpenStep/NeXTStep.
Anyway, this isn't Cocoa, so the title is (almost) inaccurate.
Cocoa consists of 2 programming interfaces, FoundationKit and AppKit; whose sole purpose is to provide a robust MVC model for programming on Mac OS X while providing an easy-to-use interface to lower-level APIs such as Carbon and CoreFoundation.
NeXTStep != OpenStep
OpenStep is meant to be a cross-platform version of NeXTStep; no system dependencies unlike NS and Cocoa.
I can see OpenStep spawning something similar to Cocoa on Windows; but at this point, it is no way shape or form similar to Cocoa. - astrosmash, on 10/12/2007, -3/+4Word.
- NSResponder, on 10/12/2007, -0/+1I'm glad to know that "superKduper" isn't at Apple anymore. Most of the luddites got with the program, and those who didn't want to learn moved on.
-jcr - astrosmash, on 10/12/2007, -2/+3From what I understand, Apple decided to implement the Finder using the Carbon APIs as a way to prove to nervous (Classic) Mac OS that the API was a viable way to move their applications to the new platform. This was way, way back before the API was solidified and way before OS X.
I believe that today it uses a mix of both Carbon and (what translates into) modern Cocoa API in the C language. If anyone could elaborate, that would be great.
One thing is for certain, the OS X implementation of Finder is very old and archaic compared with the rest of the fine software that comes bundled with OS X these days. That explains the "weird" bugs that persist in Finder, and more importantly, Apple's failure to fix these bugs. It's such a core application, that's it would be very difficult to re-write or replace, however. I'd guess they're working on it, though. - webmaniac, on 10/12/2007, -0/+1YellowBox was available for windows as a developer preview once. This was in the days when OS X was still called AppleRhapsody. When OS X was released, YellowBox was renamed Cocoa and support for windows was dropped.
See also:
http://www.cocoadev.com/index.pl?YellowBox - shinynew, on 10/12/2007, -1/+2you think thats bad, trying being me when a new shiny product is made...
- unloud, on 10/12/2007, -0/+1You mean when a shiny new product is made?
- Agrippa, on 10/12/2007, -6/+7Damn, this is pimp.
- cjwl, on 10/12/2007, -0/+1I think this is the first time anything I've done has been called "pimp"
- scottstevenson, on 10/12/2007, -0/+1This is an interesting project, but it doesn't enable current Cocoa apps to be recompiled to run on Windows. Christopher and David have apparently done some great work, but it looks like they've aimed for OpenStep. That leaves some big question marks like Core Foundation, Core Data, Core Image, Core Graphics, CFNetwork, all of the Carbon stuff, and so on. No key-value coding, observing, or binding or controller classes. That doesn't even include new API in Leopard. Modern Mac apps are more than AppKit and Foundation. Again, though, fantastic work.
- tyrione, on 10/12/2007, -0/+1My mistake. I crossed your initials with that of Greg who writes consistently on GNUstep as you do.
- spectre_25gt, on 10/12/2007, -0/+1Why was this modded down? There's evidence to that effect. It's distributed with Webobjects for Windows.
- scottstevenson, on 10/12/2007, -0/+0I think you could make the case that Cocoa now also includes Core Data (looking at Cocoa.h essentially confirms this).
- astrosmash, on 10/12/2007, -1/+1PathFinder is way too resource hungry for something that needs to run all of the time in the background. Compare its memory usage to Finder's; they differ by an order magnitude.
- inactive, on 10/12/2007, -1/+1OS X Finder is still Carbon, too, isn't it?
- Epyn, on 10/12/2007, -3/+3Funniest info/faq page I've read in a while.
- emorphien, on 10/12/2007, -7/+7I don't know why you're digging SeBBBe down, the windows version of iTunes does suck. It's better for Mac OS whether you like iTunes or not (I don't).
- skellener, on 10/12/2007, -2/+2I could never get over the fact that Apple used Carbon for The Finder. WTF??? Time to ditch it.
PathFinder does a great job as a replacement. I'm not crazy about all the bells and whistles that are added, but Apple should simply buy PathFinder, make it The Finder and allow some Preference options for the utilites PathFinder offers. - scottstevenson, on 10/12/2007, -0/+0"Apple already has a Windows runtime for Cocoa. They opted to not support it and keep Cocoa for Mac OS X. But the whole thing actually exists inside Apple."
I guess you could have some sort of inside information, but I find this extremely unlikely. It's a lot of work and there's no real reason to do it. It's also not clear if Cocoa could even be completely replicated on Windows because of things like Quartz. - mglmouser, on 10/12/2007, -2/+1Apple already has a Windows runtime for Cocoa. They opted to not support it and keep Cocoa for Mac OS X.
But the whole thing actually exists inside Apple.
But, besides Apple and this Cocoatron thing, there's also another free implementation of the OPENSTEP APIs (compare OpenSTEP wich was NeXT's implementation of OPENSTEP): GnuSTEP. - smeager, on 10/12/2007, -3/+2You do realize that Microsoft's C#, .Net, VB.Net are all types of Objective-C frameworks derived from C++. Just like Apple Objective-C Cocoa Framework.
- skymt, on 10/12/2007, -4/+3From the Cocotron "More Information" page (linked to at the bottom of the main info page):
"How is this related to GNUStep?
Similar idea but different license, authors, source and goals."
License: who cares? One's GPL, the other's MIT. Why bother? Authors: why didn't they just contribute GNUStep, a project that's already fairly mature? Source: duh. Goals: what goals? How, exactly, are the goals of the two projects different? -
Show 51 - 59 of 59 discussions
Check out the new & improved 
© Digg Inc. 2009
— Content created and posted by Digg users is