Tiger Finder Cocoa :? New form of seeing files ?
Um any developers or others here that have Tiger ? Has Finder become cocoa yet ? Is there any new form of seeing and retriveing files? I know of the cool sounding search bar at the top menu. But you will have to remeber stuff about the file to actually find it.
Is there any new method to organize the files instead of files in files ? Or does it animate any better like the zoom or tabs? Or something .... Al I remember is that I could not automate my sidebar to hotkey in the placement and removal of the sidebar items as it was not cocoa or fully applescripted, and applescript was to slow to make it usefull fast....
I do like the coreimage but will not get to use it since it requires a nasty good CG card :?
Is there any new method to organize the files instead of files in files ? Or does it animate any better like the zoom or tabs? Or something .... Al I remember is that I could not automate my sidebar to hotkey in the placement and removal of the sidebar items as it was not cocoa or fully applescripted, and applescript was to slow to make it usefull fast....
I do like the coreimage but will not get to use it since it requires a nasty good CG card :?
Comments
Originally posted by tripdragon
Um any developers or others here that have Tiger ?
Okay this one is zimple... that would be a big YES.
Originally posted by tripdragon
Has Finder become cocoa yet ?
Zimple too ... No.
Originally posted by tripdragon
Is there any new form of seeing and retriveing files?
Getting a little cloudy but... Yes?
Originally posted by tripdragon
I know of the cool sounding search bar at the top menu. But you will have to remeber stuff about the file to actually find it.
Well... errr... yes... you will STILL need to know the file exists in the first place in order to search for it after you've forgotten where you've lost it, (does that even make any sense?)
Originally posted by tripdragon
Is there any new method to organize the files instead of files in files ?
Ummmm......
Originally posted by tripdragon
Or does it animate any better like the zoom or tabs? Or something ....
Ummmm......
Originally posted by tripdragon
Al I remember is that I could not automate my sidebar to hotkey in the placement and removal of the sidebar items as it was not cocoa or fully applescripted, and applescript was to slow to make it usefull fast....
Oh okay.. then I'd have to say RUMBLE-DARN-FUS to that one!
Originally posted by tripdragon
I do like the coreimage but will not get to use it since it requires a nasty good CG card :?
I'm just gonna have to punt on this one...
Dave
Originally posted by tripdragon
hmm so no cocoa finder
It's not the fact that the Finder would be Cocoa that would make me happy. It's the fact that we'd know the Finder was rewritten that would make me happy. We'd be assured that the Finder team has gone through the entire code at least once. As opposed to the current Finder which probably has some code with cobwebs attached to it.
Carbon apps are still the ones that hang/beachball the most when there is any kind of network activity going on. Look no further than iTunes when you're doing anything with the iTMS or net radio streams and something goes haywire. The Finder when using the iDisk or Finder FTP. DVD Player and the Finder just beachball when it has difficulties reading a CD or DVD. Coincidence? Cocoa apps hang just as much? I haven't witnessed Cocoa apps hang as bad as Carbon apps. So I'm ready to blame the API.
Originally posted by ic1male
Interesting... Is there a comprehensive list anywhere of which apps are Cocoa and which are Carbon?
There are very few Carbon apps left by Apple. DVD Player, Finder and iTunes are the last of the big apps in Tiger.
I once believed that Apple wouldn't move QuickTime or iTunes to Cocoa simply because a Windows port exist and having very different codebases would make it harder for Apple to keep feature parity between the two...but QuickTime was Carbon up until Tiger. If QuickTime Player *and* the framework can move to Cocoa, I don't see why iTunes wouldn't.
There might still be a few things Carbon allows the Finder to do that Cocoa isn't able to do yet. Which may be why the Finder is still Carbon but it's probably next on the list. Or maybe Tiger's Finder is actually good now and doesn't really need to be rewritten.
There might still be a few things Carbon allows the Finder to do that Cocoa isn't able to do yet.
Do forgive me, but I'm new to Macs and find this very interesting. Why would the Finder benefit from going Cocoa? I've only been using it for a few days but think it's great. How could they make it better? What kinds of things does Cocoa offer over Carbon? Why would Finder be only able to do some things in Carbon and not in Cocoa as you mention above?
Originally posted by ic1male
Do forgive me, but I'm new to Macs and find this very interesting. Why would the Finder benefit from going Cocoa? I've only been using it for a few days but think it's great. How could they make it better? What kinds of things does Cocoa offer over Carbon? Why would Finder be only able to do some things in Carbon and not in Cocoa as you mention above?
Well back in the old 10.0 days, there were several things Carbon did that Cocoa didn't do or didn't do particularly well. Apps that relied on QuickTime, for example, didn't work very well or were limited in Cocoa. The Finder uses QuickTime to preview movies or music files.
But today, I'm not really sure what Carbon offers over Cocoa. Cocoa has more than caught up. But there might still be low level access issues that still make Carbon the better candidate for the Finder or DVD Player.
I don't really know for sure though...you'd have to ask a developer that knows his stuff and Apple's stuff.
Apple quality control seems to be sucking as of late.
Originally posted by Ra
Carbon vs. Cocoa is purely a matter for developers. According to Apple, choosing one over the other only affects how you build your application, and shouldn't affect the user experience at all. The sad reality is that there are disparities between apps written in Carbon vs. apps written in Cocoa (e.g. open up TextEdit [cocoa], start typing part of a word and press option-esc; now do the same in MS Word [carbon]).
Apple quality control seems to be sucking as of late.
Oh God, the disparity issue is a whole different story I could talk about for hours and hours.
I've grown to hate Carbon for 2 main reasons:
1-The disparity between Carbon and Cocoa because Apple can't get its shit together and make Carbon an experience that is identical to Cocoa
2-The fact that most Carbon developers are still living in an OS 9 timewarp and don't put in what Cocoa apps get for free
Originally posted by Ra
The sad reality is that there are disparities between apps written in Carbon vs. apps written in Cocoa (e.g. open up TextEdit [cocoa], start typing part of a word and press option-esc; now do the same in MS Word [carbon]).
Goodness. I didn't know that little gem. Where on earth are all those words stored? In some kind of hidden Cocoa dictionary?
Originally posted by Ra
...(e.g. open up TextEdit [cocoa], start typing part of a word and press option-esc; now do the same in MS Word [carbon]).
Apple quality control seems to be sucking as of late.
gorgeous.
A bigger reason why there are disparities between Carbon apps and Cocoa apps (you can actually mix and match these languages and libraries) is because those Carbon apps use older legacy code from the Classic OS. Developers don't necessarily want to rewrite their old code more than they have to either because it's either fragile and labyrinthian or because it's just not cost-effective to invest the time to do it. That's arguably a big reason why people have problems with how the Finder behaves, and why apps like Word and Photoshop don't incorporate features that are available for "free" to Cocoa apps.
Besides, no one *has* to use Apple's included tools, and while Office imitates some OS X features that most Cocoa developers use, MS likes to roll its own dough, as does Adobe. Apple can't control what these guys do, they can only encourage them to get on the bandwagon.
Finally, while I don't think the Finder will disappear altogether, I think Jobs, Tevnanian and Serlet see the Finder's role diminishing and that it isn't worth "fixing" too much because it isn't a strategic or important part of the OS in their future plans. I think it will still get fixes, revisions, some new features, but I doubt they will go through the effort of reinventing the wheel so to speak since the big picture sees the Finder as only a spare tire, if I may mix metaphors a bit.
AppKit Teams, Foundation Teams so on and so forth bent over backwards to salvage the OS 8.x APIs and repackaged them as Carbon. It has been updated to maintain backward compatibility for years now, including some updates to current functionality. Now that the MVC paradigms of Cocoa are finally being showcased, along with the fact that C++, Java and several other interpreted languages can access Cocoa's extensive frameworks people have much less to whine about. It was such a pain in the rear at Apple before I left the Enterprise Team to hear all the whining about legacy crap.
Politically,
Carbon vs. Cocoa is purely a matter for developers is what Steve spun after WWDC 1998 when he told everyone that Carbon was just a transitional API to satisfy the likes of Macromedia, Adobe and Microsoft.
But Steve and Avie made this clear. It is a transitional API. When Jon Rubinstein was asked back along with Sina to oversee World Wide applications really should have caught more peoples eyes.
http://www.apple.com/pr/bios/
All but Tim, Ron, Peter and Phil worked at NeXT in similar positions.
Having worked both at NeXT and Apple I do have some background on this history.
I still predict OS XI to be the first Pure Cocoa Version of Mac OS.
Seeing that QuickTime is now Cocoa, expect iTunes to be Cocoa.
By the way, Cocoa on Windows is easy. We ported Openstep 4.1 to Windows back in 1996. It is known to Mac folks as Yellow Box.
Originally posted by Ra
Carbon vs. Cocoa is purely a matter for developers. According to Apple, choosing one over the other only affects how you build your application, and shouldn't affect the user experience at all. The sad reality is that there are disparities between apps written in Carbon vs. apps written in Cocoa (e.g. open up TextEdit [cocoa], start typing part of a word and press option-esc; now do the same in MS Word [carbon]).
Apple quality control seems to be sucking as of late.
The cocoa vs carbon debate is quite old, and yet, it always seems to go for a couple of spins when brought up.
While I agree that Cocoa is a better API than Carbon, I don't agree that it is inherently the best choice for all projects. Cocoa's main benefit is that it speeds up development and decreases the cognitive load on developers. However, if a development team and code base is already Carbon based, Carbon can be the better choice.
Also note that the next release of quicktime is NOT cocoa. The QT player will use a new Cocoa view. However, the vast majority of legacy QT code remains. We're talking millions of lines of code! As Apple's new 'core' technologies mature, they are slowly replacing bits of quicktime where possible. Yet to completely rewrite iTunes and Quicktime in Cocoa would lead to delayed release schedules and buggy software.
Merely being a 'better' API does not make cocoa the better choice when releasing a new version of existing software. Scrapping tried and true code bases is an expensive, time consuming, and catastrophe prone undertaking.
Finally, while openstep was cross-platform, since it's last release, cocoa was born and melded with many propriety and legacy Mac APIs. While the yellow box could be alive and well, we have no indication to believe that it is.
Originally posted by dfiler
Also note that the next release of quicktime is NOT cocoa. The QT player will use a new Cocoa view. However, the vast majority of legacy QT code remains. We're talking millions of lines of code! As Apple's new 'core' technologies mature, they are slowly replacing bits of quicktime where possible. Yet to completely rewrite iTunes and Quicktime in Cocoa would lead to delayed release schedules and buggy software.
Um... CoreImage/Video/Audio make up the new QuickTime base. Really. And they, unlike the old QT code, are nicely re-entrant, thread-safe, and ready for Cocoa at any time. They're quite nice.
QT 7 will be a thin layer over CI/A/V, and will be Cocoa and Carbon.
Originally posted by Kickaha
Um... CoreImage/Video/Audio make up the new QuickTime base. Really.
I could be wrong about this but...
I'm under the impression that some types of processing are being handed off whenever possible. Yet, the majority of legacy code is still there. The quicktime codebase is absolutely huge, comprising much of what was once OS 9. This is true even on the windows side.
I muck about with legacy code on a daily basis, although it is database work instead of multimedia work. Typically, we phase in new code but leave much of the original work intact but bypassed. Essentially, we add another layer and make the old layer forward calls whenever possible. This is an ugly and unsatisfying approach but it does seem to work.
Anyone have insider insight on how apple has replumbed QT?
(Especially with regards to windows QT)
Now, the CI/V/A APIs are generally close enough to be replacements for QT calls in many cases, at least in semantics if not in exact syntax. QT is a nasty API in general IMO. It's gotten slightly better in the QT6 age, but not by much.
After CI/V/A have been more thoroughly battle tested, expect to see a QT API that sits on top of them. A Cocoa QT API, no less. There will likely be a Carbon QT API around still, but it will also sit on top of CI/V/A.
No idea what they're planning on doing on the Windows front. Probably keep the existing codebase, and simply make the Mac QT developing experience richer. Playback will likely be the same.
The magnitude of such a change is why I was envisioning the additional-layer approach to deprecating APIs.
I've been ready to have my socks blown off by a rewritten QT for a while now.
It will be a real milestone in the software industry. There have been only a handful of transitions of this magnitude. Windows XP and OS X are the most analogous. QT really is that much of a cross platform behemoth. Scrapping a code base this messy and huge will not be a trivial undertaking!
I do believe that apple is hard at work to completely replace much of the quicktime infrastructure. Yet many of the relatively black-box-esque codecs and orphaned bits of code may live on for decades. It?s good to hear that those closer to the action are saying we?re farther down that path than I thought.
Originally posted by Kickaha
No idea what they're planning on doing on the Windows front. Probably keep the existing codebase, and simply make the Mac QT developing experience richer. Playback will likely be the same.
While re-reading your post, something interesting dawned on me.
The success of the iPod and iTunes changes how apple can position QT in the media standards market. Perhaps they can now be less paranoid about loosing their influence on media standards.
I'd long realized that the iPod and iTunes was a great trojan horse for getting QT installed on windows machines. But maybe it goes farther than that. Could apple open source much of the old QT after transitioning to core*?