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.
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.
"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.
Finally re-writing the finder in Cocoa would be a good start. That's the cause of a lot of problems.
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.
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.
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.
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.
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.
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
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.
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).
Quote:
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.
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.
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).
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.
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.
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).
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.
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.
Agreed.
Quote:
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.
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)?
Comments
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.
Originally posted by Hiro
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.
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
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.
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!
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.
Originally posted by melgross
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!
Originally posted by melgross
Finally re-writing the finder in Cocoa would be a good start. That's the cause of a lot of problems.
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.
Originally posted by Hiro
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.
Originally posted by Hiro
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
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.
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.
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
Originally posted by jccbin
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.
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).
Quote:
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.
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.
Originally posted by Hiro
Cocoa won't make the Finder any better.
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).
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.
Originally posted by Hiro
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.
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.
Originally posted by Programmer
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).
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.
Originally posted by kim kap sol
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.
Agreed.
Quote:
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.
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)?