Sources: Intel developing next-generation Power Mac for Apple - Page 9

And replacing it with ...? I'm seriously curious because I think the desktop/file/folder metaphor is past its prime, regardless of its current stranglehold on computing. From a long-term usability perspective I don't see it scaling well.

Who do you ask about indexing and cross referencing information effectively? Library Scientists.

Truth be told, I don't see much they have implemented that will outperform or out ease a really well done Spotlight style interface. I don't think Spotlight is quite there yet, but I don't see the librarians delivering any new quantum leaps in the next couple years.

That's the key though. We don't have a really well done Spotlight interface yet. The current one is very slow when you've got 500MB+ of data and dire when you've got multiple drives which are potentially asleep. I've had to switch off the option to allow my drives to sleep when not used as Spotlight takes ages to start them up.

And searching for everything when you already know where it is is a strange concept. It's a level of redirection which doesn't happen in real life.

It also seems to be badly bolted on to a creaky old Finder that has lost it's identity after OS9. I'd forgotten how good the Finder was back then till I had to use an old G4 I was given to fix. It's quite refreshing to have things stay where you put them, the view stay as it was set and even the position in the list in the window stay as you left it. Sure, I missed column view but they seem to have forgotten the Finder's strengths when they added that.

I'm still hoping that with the strength of the ex-BeOS talent at Apple, we'll see something as elegant, as powerful and as fast as the BeOS tracker.

i think apple has made a bold if sometimes bizarre attempt of ditching the file/folder metaphor via spotlight.

the thing though is that things may be generally easier to find, but backing up would be insane if i had my files totally all over the bloody place and anyway....most people don't have a spare 60gb external lying around to just "backup their entire user folder" or to do carbonCopy or superDuper.

maybe 10.4.4 spotlight, when you burn a cd to backup your files, it will do smart folder --> burnt cd much much better? hmmm.

Finally re-writing the finder in Cocoa would be a good start. That's the cause of a lot of problems.

I really do hate to do this but this link is sort of on or at least not too far from topic. I know that's bad forn by now, but...

Read down. A showing of Apple at the CES by Ottellini.

http://www.theinquirer.net/?article=28771

Someone asked about the the possibilitty of Ottellini saying something about apple during the show.

Well, here it is!

"Otellini showed an Apple machine running Internet applications as well as a Blackberry" .... ??? does this mean that Otellini was showing a Macintel? or a windows PC playing quicktime or itunes or something? WTF?

his keynote "archived" will be "available soon" on this site.
http://www.intel.com/personal/ces_20...elet/index.htm

hmm.. we really need more details on what "apple" he actually showed.

That's awesome.

Cocoa won't make the Finder any better.

Period.

A sane rewrite of the Finder is in order and it doesn't really matter if it is Cocoa or Carbon.

In all seriousness there are quite a few Cocoa methods which are simple wrappers around perfectly good Carbon code -- which would make those Cocoa calls slower by another stack frame call. You really need to know what you are talking about before spouting off on automagical API fairy dust solutions, they just don't exist. It just takes good old fashioned hard work and a good design, independent of the API flavor used.

That's interesting, as most technical writers over the years on the subject disagree with you.

Riiighhhtt. And the Tooth Fairy exists.

I think that mdriftmeyer's post her is current of the developer thinking I've been hearing. You can dispute it with him as well if you like. I don't currently do this work myself.

http://forums.appleinsider.com/showt...0&pagenumber=3

You read way to much into that post. Do some searches on the Carbon vs Cocoa smackdown matches that have gone on here over the last couple years.

Carbon's not going anywhere, it is on a more than equal footing with Cocoa. Just about all of QT is Carbon which means a good chunk of the Cocoa graphics layer is just Cocoa wrappers calling Carbon code. And that's just the simplest example.

Cocoa is just easier to write new stuff from scratch, not faster or better running.

Cocoa is Apple's preferred toolset.

Carbon was a compromise with the classic developers to keep them onboard with OS X. If Apple could have forced them all to move to Obj-C, they would have, and still plan to eliminate Carbon, per se.

Just as programming hooks are deprecated out over time as new ways are created, Carbon will be eliminated. For that matter, EVERYTHING is subject to eventual deprecation. You can be your bottom dollar that the term Carbon will die, even if some of the code remains. It is associated with Classic, and Classic is in the ash-heap, beginning this year.

Paul Otellini Keynote at CES 2006

Q. was an Apple Mac shown?
A. not really, Paul talks about "the digital multitasker" and the slideshow graphic appears to show clearly a PowerBook without any markings, an iPod, a Blackberry among other things, but the PowerBook has a simulated screen with windows applications

Q. was Apple iTunes being demoed?
A. yes, alongside a service called "Modeo" or something

Q. was it just playing an mp3 or a video?
A. no, they were showing ripping an audio cd using iTunes while playing "Modeo" video and uploading pictures from a digital camera

Q. was it running on Windows XP pro?
A. it appears to run on a Windows platform of some sort

Q. why are people trying to pitch this as "Intel Hates Microsoft"?
A. i think intel is trying to pitch itself to as wide a market as possible, that's their vision now, to not be held back by any one company, or to not be too dependent on any one company.

Q. can i play the latest PC games on my Mac Intel laptop?
A. possibly Paul showed Quake4 running 60fps in an average gaming situation, Quake4 optimised for dualcore. no information on what video card the LAPTOP he was demoing had, resolution, etc. and of course, dual-booting Mac OS X intel and Windows or Linux is unknown at this stage

I don't see why.

Carbon has useful APIs Cocoa lacks. Carbon events are simpler to use and lightweight. The File Manager has a lightweight opaque object, the FSRef, which doesn't have a Cocoa or UNIX equivalent. Unlike file descriptors, one can determine what a file's path given the FSRef. This means an application can keep track of open files instead of assuming the path never changes. This also works on UFS volumes (unlike FileIDs).


Carbon won't die. Cocoa isn't a drop-in replacement for Carbon anyway. Cocoa is higher-level. Plus Cocoa requires an objective language to use.

I wish everything was subject to deprecation, but it doesn't seem to be the case with the Cocoa sacred cow. Only with 10.1 did NSDocuments use FSRefs internally so it didn't lose track of files, but Cocoa still uses the easily broken POSIX file path to refer to files. One of the best human interface advances Apple made was with System 7, where functions dealing with file paths were deprecated in favour of FSRefs and Alias Handles.

In some respects we're retrogressing.

I think you take that too literally.

A Cocoa Finder would have to be a from-scratch rewrite simply because you cannot really convert to it. Ergo they would have to go back to basics instead of piling more onto the creaking frame of the current Finder. The Cocoa API tends to be considerably more robust and faster to develop it, which means they could either deliver sooner or go farther. No functionality is lost because a Cocoa app can call pretty much any Carbon API if it really wants to.

The extra layer of function calls is not going to significantly impact performance of a rewritten replacement Finder -- the performance problems are far more related to the architecture, algorithms, other design issues. The call overhead might represent a couple of percent lost in places where it doesn't really matter.

So the Finder being in Cocoa wouldn't directly make it better, but the act of rewriting in Cocoa probably would (unless they really botched it, of course, but the modern Apple seems to be better about their software development than the Apple of 10 years ago so I'd be surprised if that happened AND it shipped).

That was well said, and was more of what I meant.

The lament about the Finder being in Carbon is that it has many known problems which will seemingly not be fixed. It's been five years.

If it were rewritten in Cocoa, and many have suggested would be a good idea, starting from a new code base, those problems would be fixed.

Oops, just saw my spelling for Cocoa.

One framework won't make any app better than another...that's up to the developer. We all know that. But lets face it, Apple will get the job done faster if they use Cocoa. And a complete rewrite is the only thing that will save the Finder at this point...especially since hierarchical navigation is going the way of the Dodo and being replaced with metadata navigation.

But please, if you want to tell us it doesn't really matter which framework you use or which language you use to develop an app, write a complete graphical app accepted by today's standards using assembly...show us how frameworks don't matter.

Agreed, hence my calling for a sane rewrite of the Finder. It's not the API, it's the design. And yes, changing the API can prevent the developers from being lazy and force the developer to do it all from scratch rather than do a more Frankenstein effort. I see that as more of a discipline of design issue, than an API issue, that's all.

Agreed.


Just a little histrionics there? You are the gent ranting about assembler, not I.

Cocoa/Carbon hardly have a high level/assembler relationship. Sure Cocoa is a bit higher level than Carbon, but the frameworks have a roughly synonymous functionality until you get to the Core Data/Graphics/Video frameworks (which are Cocoa only). Carbon API's is quite capable of supporting a respectable GUI app, although why anyone would want to start a new app that way when Cocoa is available is a good question.

If anything Carbon is slowly evolving into Core Foundation which is more than less a cleaning-up and formalization of the "wrapped-up" Carbon code, but neither Carbon nor Cocoa. Isn't that just like Apple, muddling the meaning of Core, three API's which are Cocoa only and two that are Cocoa/Carbon agnostic, and even advertised as somewhat cross platform (CF-Lite/CFNetwork)?

None of you seem to really get it. There already exists a Cocoa Finder. How it evolves into OS X 10.5 is up to the design team.

There was a Cocoa Finder back in 1997. The Finder was redeveloped to address the Classic/Carbon issues and thus the Cocoa Finder (Workspace Manager and future children) were put on hold.

When Steve stated that OS X for Intel has been built since 2000 he isn't telling the entire story. It was built since 1997/98 as Rhapsody for Intel.

He synced up the dates when OS X was first hobbled out.

People need to realize a ton of work went into reinventing the wheel just to keep legacy developers happy FOR OVER SEVEN YEARS.

COCOA is the Future of OS X.

Don't believe me. Go get a job at Apple Engineering.

I don't think you really understand what's been said already.

The line between Carbon and Cocoa is so blurred nowadays, it's pointless to dispute this anymore. A "Cocoa" Fnder would perform no more or less poorly than the current Finder. Rewriting IMHO would njot provide any huge benefit.

If anybody cares to remember, iMovie was a Carbon application. Then with iLife 05 Apple rewrote it as a Cocoa application. It was S-L-O-W as molasses. So much so that they released two successive updates to make performance tweaks. It still feels like it's got molasses stuck to its GUI widgets. The same thing with iPhoto, which was written from scratch as a Cocoa application.

The Finder's problems stem from three problems:

• A poorly designed network filesystem implementation. The spinning wheel of death when using AFP or WebDAV has nothing to do with Cocoa vs. Carbon; that fact can be confirmed by running a dev tool like Sample on the Finder when it starts spinning. Anybody with knowledge of OS X programming could see that the Finder is spinning because the underlying filesystem call like stat() (a BSD call that Cocoa would use as well) is blocking, waiting for the networking operation to complete. Now, they COULD put that operation on a seperate thread, but that brings me to my next point.
• All GUI calls on OS X are un-thread safe. Cocoa and Carbon are both un-threadsafe WRT to their widget API calls. Anybody that's tried to update an NSTableView from inside a thread will tell you that Cocoa is no better than Carbon in this area. So the Finder team cannot just spawn a new thread to update the GUI, because the GUI cannot be updated from inside a thread. And it's impossible to tell if a filesystem API call will block before you call it.
• Blocking APIs are NECESSARY when working with files in order to ensure consistent and non destructive behavior. For example the user might click on a file, causing the finder to call stat() on it so they can determine the permissions of the file (so you know what operations are permitted on the file). If they spawned a thread when you clicked on the file to call stat(), then what happens in the mean time? Should you be allowed to double click the file? You may not have permissions to do so.

The Finder has other problems besides the networking filesystem, but they are mainly problems as far as I can tell with the underlying frameworks of OS X, not with the implementation of the Finder.

It's ludicrious to think that Carbon vs. Cocoa actually makes a difference anymore. Several APIs in Cocoa are built ON TOP OF Carbon, and Carbon makes use of Cocoa calls as well. Cocoa's Menus are drawn with Carbon; events in Cocoa are dispatched using Carbon Events.

Furthermore, what IS Carbon? Is it anything not Objective-C based? Is it APIs that came from OS 9? If so, then the QuickTime, AppleScript, and many other OS X frameworks that Apple tout so heavily would go away if Apple were to get rid of Carbon.

If you are STRICTLY speaking about the widget APIs in Carbon.framework, then you are talking about something that cannot possibly affect performance, etc. on the order of magnitude that most people assume.

Come back when you've learnt how to read.

holy f*** this thead really needs to be locked. 9 pages, almost all of them off topic

This isn't a showstopper, it just means the application needs to take care of moving the data from the worker threads to the GUI thread.

That's not the point. The point is Cocoa doesn't help.

You don't want a 100% Cocoa Finder anyway. It wouldn't even be able to handle Aliases.

What exactly would you want to use Cocoa APIs? The views? What would THAT solve?!

Well if you'd read the discussion above you'd see that the use of Cocoa in-and-of itself wouldn't solve anything. To have a Cocoa Finder would imply a complete re-write, however, and perhaps then we'd have one that would solve the often made complaints.