What incompatibilities there are have everything to do with the changes from Java 1.3 to Java 1.4.1 and Apple's as-yet-incomplete implementation of 1.4.1. The move from Carbon to Cocoa underneath should have absolutely no effect on compatibility. What it does is reduce the number of man-hours required for design, coding and testing, and the number of lines of code that can introduce bugs. That's why Apple's moving so much development to Cocoa: They can get more done in less time with fewer programmers, and with fewer lines of code.
please read the release notes from apple on its java 1.4.1 release.
Quote:
One persistent fallacy in this thread is that an application has to be Carbon or Cocoa. Nothing at all prevents a vendor with a big C++ app linked to Carbon from redoing the GUI in IB and the view layer(s) in Cocoa, and linking against a Carbon back end. The issues are: How well-factored is the code, how quickly can the developers get up to speed (Apple argues, from their own experience, that this curve is relatively low), and how many advantages can be gained from linking to a framework like Cocoa and (optionally) from a lean, dynamic language like Objective-C.
do you know any big vendor working on moving the front end, GUI part, to cocoa? also let me ask this simple: which way is easier for, any, vendor who has hugh existing carbon code base, to do: using existing carbon code to have its applications on mac os x or creating cocoa code to into face carbon code?
Quote:
In fact, any Cocoa app that deals with QuickTime is going to have a healthy amount of Carbon code in it.
i hope the situation, where cocoa app uses carbon which then uses cocoa, will not occur.
Quote:
Ideally, the customers shouldn't notice.
you misuderstood my piont: customers i mentioned are not the end users, like you and me. apple's customers in developing communities are developers, both big name and small kids. of course, these "customers" will notice the hugh differences.
Quote:
Along these lines, A Cocoa Finder will make little to no difference to any other applications (whose interactions with the Finder are pretty minimal as it is). They pop the same windows, get the same events, and so forth. They handle these things differently internally, but what they do internally is irrelevant. Currently, Finder forwards most events to an application called System Events. If that doesn't change, nobody will notice whether Apple recodes the Finder in Objective-C/Cocoa, or in pure Java.
yes, end user will never notice the differences on whatever changes in the Finder. but developers notices it when they program and debug. you could argue that changes are minimal to developers too. but my concern is that what will happen to an existing application where the behaviors, event machenism changes, cause their debugging difficulties.
i am still using gcc 2.95 release though it is 3.2(?) already. why? changes in newer version broke hugh part of support libraries in my product code. should i work to correct those imcompatibilities? i wish i have enough capable man and money.
Quote:
(This assumes that Apple doesn't intend to completely reinvent the Finder, rather than simply moving the existing Finder to Cocoa. In that case, the reinvention would be what sparked the change, since it would be different even if Apple had kept it a Carbon app.)
i hope the same hope as you do. keep in mind, when people innovate things, they tend to follow the flow, not rationales. :-)
Quote:
Why?! Carbon suffices for some cross-platform and old-school Macintosh developers, and for apps like Ambrosia's Snapz Pro that are better served with a low-level API. Cocoa brings over all the old NeXT applications easily and provides a very attractive way to develop Mac applications, especially for small developers. Java brings in a whole other audience as well. None of these APIs are going to go anywhere, and none of them are being neglected. In fact, Apple has been hard at work unifying them over CoreFoundation. Cocoa and Carbon and C and C++ and Objective-C can be commingled freely, and Python and Java and AppleScript can talk to them and be linked to them. This integration is getting tighter and more complete with every release. There's no need for anything new; if something new comes along (Microsoft's .NET?) it can be built on top of the same Foundation that the rest are, and join the party.
MS is different animal while apple is a lean surviver, now. so supporting two api for apple is not easy as reality is that hugh amount of support effort goes to carbon support where bigger developers demand. i am not sure how many big developers jump onto the cocoa bandwagon, but one thing that is obvious is that since the relation between apple and its developers is mutual, without big developer supports, cocoa is crippled: on the one hand, the cost to have this wonderful technology is not a non-issue anymore, if current economy situation persists; on the other hand, cocoa needs to have some serious execises in bigger apps, not just some pet app you and i create, with all due respect.
Quote:
The real issue here is that the final appearance, reliability, performance and polish of an application is up to the developers, not the API (although the language and API chosen will help or hinder these goals variously — it's the developer's job to pick the most appropriate ones). Whether it's a Cocoa app, or Carbon, or Java, or RealBasic, or AppleScript Studio, or what-have-you should be completely transparent to the end user. In the end, a Mac application is a Mac application; if it isn't, the developers didn't do their jobs.
in apple's case, blames more or less reside on apple's head. let us not dig up the old shabby history how apple treated its developers as i still have my OpenDoc developer sdk and books... let us assume microsoft starts to use cocoa for their mac products. but one day, let us say 1.5 year from now, apple decided to cancel cocoa or cease its developing. what will happen? the same thing is true for carbon. apple is apple, if some one else it has been dead zillions of times already if the scenario happens.
the situation i sense now is that big developers are united and demand apple have a carbon api, which used to be thought as a transition to cocoa but now a parallel api to cocoa, for their products. developers, either microsoft or adobe, are apple's another important customers, beside the end users at apple stores or homes. maybe apple could dump all of them and have everything inhouse. in this case, i rest my case.
last, we are getting too long on the exchange. if you want to discuss further, email me.
please read the release notes from apple on its java 1.4.1 release.
I have. They were the basis for my point.
Java 1.4.1 breaks things chiefly because they didn't implement the whole thing. The fact that it's now in Cocoa is irrelevant to Java developers, except that the bridge to Cocoa is now much nicer (obviously). Pure Java developers won't notice Cocoa. They will notice the bugs and omissions in Apple's implementation of 1.4.1.
Quote:
do you know any big vendor working on moving the front end, GUI part, to cocoa? also let me ask this simple: which way is easier for, any, vendor who has hugh existing carbon code base, to do: using existing carbon code to have its applications on mac os x or creating cocoa code to into face carbon code?
The least time I checked, Apple itself was a big vendor.
As for the rest, I don't know. I don't pay much attention to big vendors precisely because of issues like this. It remains to be seen if QXP6 does, since they swear up and down that it's OS X native (on the other hand, this is Quark...). Adobe has their own platform with their own interface, so I doubt they use too many native widgets anywhere.
Quote:
i hope the situation, where cocoa app uses carbon which then uses cocoa, will not occur.
I don't see how it's possible.
Quote:
you misuderstood my piont: customers i mentioned are not the end users, like you and me. apple's customers in developing communities are developers, both big name and small kids. of course, these "customers" will notice the hugh differences.
Maybe and maybe not. Certainly not as much as a compiler change (particularly not a gcc compiler change, since gcc has a well-established reputation for breaking things between versions).
The differences will matter most as far as interfacing closely with an application, i.e. using its scripting dictionary, or (if the developer allowed) querying the runtime for methods to hook in to or augment with categories. The events sent and received from Cocoa and from Carbon Events should be indistinguishable. If they are not now, it's because Apple hasn't finished integrating the two.
Quote:
yes, end user will never notice the differences on whatever changes in the Finder. but developers notices it when they program and debug. you could argue that changes are minimal to developers too. but my concern is that what will happen to an existing application where the behaviors, event machenism changes, cause their debugging difficulties.
If the event mechanism changes, it'll change in both.
Quote:
i am still using gcc 2.95 release though it is 3.2(?) already. why? changes in newer version broke hugh part of support libraries in my product code. should i work to correct those imcompatibilities? i wish i have enough capable man and money.
Yeah, gcc is famous for doing that on all platforms. It has nothing to do with Carbon or Cocoa, or OS X's event handling.
Quote:
MS is different animal while apple is a lean surviver, now. so supporting two api for apple is not easy as reality is that hugh amount of support effort goes to carbon support where bigger developers demand. i am not sure how many big developers jump onto the cocoa bandwagon, but one thing that is obvious is that since the relation between apple and its developers is mutual, without big developer supports, cocoa is crippled: on the one hand, the cost to have this wonderful technology is not a non-issue anymore, if current economy situation persists; on the other hand, cocoa needs to have some serious execises in bigger apps, not just some pet app you and i create, with all due respect.
First, while the big Mac developers are important, they are far from the whole story. Apple is jumping on the Cocoa wagon with both feet: Abandoning Cocoa even at this early point would mean porting a whole slew of their own apps back to Carbon, with the attendant increases in bugs, programmers required and time taken. They seem to be doing all new development in Cocoa exclusively, and I can't blame them.
Second, there is the whole halo of Cocoa apps, many of which are not as visible as Photoshop but which are no less important for that, which would get cut out. Cocoa has enterprise cred.
Lastly, Cocoa is Apple's carrot to entice new development (and, as above, Apple themselves are doing new development in Cocoa. Take it away, and programming for OS X becomes that much less appetizing. Oh, and both Project Builder and Interface Builder (Cocoa apps long since) break, and have to be rewritten with, again, more programmers, more time, more lines of code, etc.
Apple is not abandoning either Carbon or Cocoa. It's not happening. I think you're overstating this issue dramatically.
Quote:
let us assume microsoft starts to use cocoa for their mac products. but one day, let us say 1.5 year from now, apple decided to cancel cocoa or cease its developing. what will happen? the same thing is true for carbon. apple is apple, if some one else it has been dead zillions of times already if the scenario happens.
But if Apple uses it, what happens?
Quote:
the situation i sense now is that big developers are united and demand apple have a carbon api, which used to be thought as a transition to cocoa but now a parallel api to cocoa, for their products. developers, either microsoft or adobe, are apple's another important customers, beside the end users at apple stores or homes. maybe apple could dump all of them and have everything inhouse. in this case, i rest my case.
last, we are getting too long on the exchange. if you want to discuss further, email me.
Carbon was always pitched as a permanent API. It was pitched as a transition API from OS 9 to OS X, not from Carbon to Cocoa.
I'll answer here, because this is an interesting issue, and I'd be interested in input from the other developers here.
[list=1][*]"User at the Center features will make it simpler for individual users to personalize their computing experience and to move seamlessly among Macs and other devices."[*]Fast user switching[*]Piles[*]"Panther will add more database-like structures to the file system, although the underlying file system will remain HFS+, ensuring backward compatibility."[*]Improved I/O performance [*]"Sources also said Apple will provide full 64-bit support in Panther."[/list=1]
All in all, nothing that hasn't been discussed ad infinitum at these boards. We'll see how reliable their "source" is when Panther ships I guess...
Rothenburg has a pretty good track record. I've been burned once or twice when I've doubted him.
Quote:
Originally posted by NETROMac
"User at the Center features will make it simpler for individual users to personalize their computing experience and to move seamlessly among Macs and other devices."
One thing this does point to is a specific concept that's fueling, directing development. The article seems a bit short on more such features, but as you said, many if not most have been discussed here already. The reported "metal" theme, or more flexible appearances in general, possibly more work done to the directory layout or rather some abstraction of it to feel more personalized, smart folders and piles, etc are all ideas that fit this agenda. Am I missing any?
Quote:
"Panther will add more database-like structures to the file system, although the underlying file system will remain HFS+, ensuring backward compatibility."
This is more like what I was expecting than a new FS altogether. This was the talk after the journaling plugin was introduced to HFS+ so why not other stuff too?
This is more like what I was expecting than a new FS altogether. This was the talk after the journaling plugin was introduced to HFS+ so why not other stuff too?
One question: Are there any limitations or problems with taking this approach instead of making a new file system from "scratch"?
Pros:
- Backwards compatibility
- Tried and tested file system
- Possible to update file system w/o (re)formatting.
The only thing I would change in your pros/cons list is that it probably decreases development time as opposed to starting from scratch. The problems in developing each feature for the existing FS would still take a lot less time than trying to develop all the features of the new FS.
- Possible to update file system w/o (re)formatting.
- Faster development
Cons:
- Speed hit
- Difficulties to implement new features
- Limitations in architecture?
The last two cons are addressed by Apple's choice of VFS (virtual file system) as the logical filesystem. VFS has a plug-in architecture, so you could, for example, write plug-ins to PGP-encrypt every file as it was saved, and unencrypt it as it was opened, and no application would be the wiser.
Applications use VFS. HFS+ just happens to be the underlying actual filesystem. But because of VFS and its architecture, you can put all kinds of nifty things between the applications and the filesystem, without requiring reformats or modifications to code.
Stacking File Systems -- Apple does not support the development of stacking VFS plug-ins on Mac OS X. We've taken this position because, in our opinion, it's not possible to create a stacking VFS plug-in that:[list=1][*]works reliably,[*]does not severely impinge on system performance, and[*]has any hope of binary (or even source-level) compatibility with future systems.[/list=1] Earlier Apple documentation stated that stacking VFS plug-ins could be used to solve certain problems, such as file-level encryption and virus checking. We even went so far as to publish an example of this, the Politically Correct file system (PCFS), that ran on pre-release builds of Mac OS X. Subsequent experience has shown that this technique does not work properly and we no longer support it. Thus, we have removed (or soon will) all references to stacking VFS from our documentation and we will not publish an update to PCFS. The existing PCFS source code is not useful because it has not been updated to support the Unified Buffer Cache.
Interesting... is this in any way contradicting your post Amorph?
Does this in any way imply that we'll get a new FS
Here is some information frome the article on how different browsing methods could be implemented.
Quote:
Even a glance at Apple's HIG 1992 paper shows a thoroughness and inquisitiveness that's lackingin much of today's software. Rather than being contented with the Pile, the team was weighing pros and cones of how it should behave, using iterative user feedback. For example, the researchers identified four kinds of browsing methods: an "edge" method where users looked for clues from the outlines of documents in the stack; a "restack" method, where users took documents off the top to reveal the next; a "hinge" method, which sounds very much like leafing through a book, stopping at various points, and a "spread" method which empties the contents of the pile on the floor, so to speak. They explored the optimal structure of a Pile viewing "Cone".
Isn't journaliing in Jaguar a basic proof of concept though? Would other such enhancements really be procluded from an HFS+ extension/plug-in in a similar vein?
Apple-X Exclusive: Be the first on your block to see what could be the first leaked Panther screen-shots!
We received a little surprise in our e-mail tonight containing two screen shots suspected of coming from Mac OS 10.3; code-named Panther. According to our source the images are from an early build of 10.3, build 7D15. With to the trained eye, I personally could not find any flaws in the screen-shots. What I did notice is that the Mac OS X logo and Apple logo in the right hand corner appear to be darker. The highlight color is also darker but this can easily be changed in any current version of OS X. Another interesting thing to note is the addition of a new item in the "default" dock which is a sample application from developer-tools with an icon featuring a compass (Not like the Safari icon but the thing you make circles with.) and what looks like a blueprint. The dock also appears to be slightly more transparent and lastly the hard drive icon has a green light on it compared to the yellow light found on Jaguar OS X icons. While it is not known wether or not these images are real, I guess we will just have to wait and see if we receive cease-and-desist order, thus proving validity of the images. So for now I leave the decision to you.
Comments
Originally posted by Amorph
What incompatibilities there are have everything to do with the changes from Java 1.3 to Java 1.4.1 and Apple's as-yet-incomplete implementation of 1.4.1. The move from Carbon to Cocoa underneath should have absolutely no effect on compatibility. What it does is reduce the number of man-hours required for design, coding and testing, and the number of lines of code that can introduce bugs. That's why Apple's moving so much development to Cocoa: They can get more done in less time with fewer programmers, and with fewer lines of code.
please read the release notes from apple on its java 1.4.1 release.
One persistent fallacy in this thread is that an application has to be Carbon or Cocoa. Nothing at all prevents a vendor with a big C++ app linked to Carbon from redoing the GUI in IB and the view layer(s) in Cocoa, and linking against a Carbon back end. The issues are: How well-factored is the code, how quickly can the developers get up to speed (Apple argues, from their own experience, that this curve is relatively low), and how many advantages can be gained from linking to a framework like Cocoa and (optionally) from a lean, dynamic language like Objective-C.
do you know any big vendor working on moving the front end, GUI part, to cocoa? also let me ask this simple: which way is easier for, any, vendor who has hugh existing carbon code base, to do: using existing carbon code to have its applications on mac os x or creating cocoa code to into face carbon code?
In fact, any Cocoa app that deals with QuickTime is going to have a healthy amount of Carbon code in it.
i hope the situation, where cocoa app uses carbon which then uses cocoa, will not occur.
Ideally, the customers shouldn't notice.
you misuderstood my piont: customers i mentioned are not the end users, like you and me. apple's customers in developing communities are developers, both big name and small kids. of course, these "customers" will notice the hugh differences.
Along these lines, A Cocoa Finder will make little to no difference to any other applications (whose interactions with the Finder are pretty minimal as it is). They pop the same windows, get the same events, and so forth. They handle these things differently internally, but what they do internally is irrelevant. Currently, Finder forwards most events to an application called System Events. If that doesn't change, nobody will notice whether Apple recodes the Finder in Objective-C/Cocoa, or in pure Java.
yes, end user will never notice the differences on whatever changes in the Finder. but developers notices it when they program and debug. you could argue that changes are minimal to developers too. but my concern is that what will happen to an existing application where the behaviors, event machenism changes, cause their debugging difficulties.
i am still using gcc 2.95 release though it is 3.2(?) already. why? changes in newer version broke hugh part of support libraries in my product code. should i work to correct those imcompatibilities? i wish i have enough capable man and money.
(This assumes that Apple doesn't intend to completely reinvent the Finder, rather than simply moving the existing Finder to Cocoa. In that case, the reinvention would be what sparked the change, since it would be different even if Apple had kept it a Carbon app.)
i hope the same hope as you do. keep in mind, when people innovate things, they tend to follow the flow, not rationales. :-)
Why?! Carbon suffices for some cross-platform and old-school Macintosh developers, and for apps like Ambrosia's Snapz Pro that are better served with a low-level API. Cocoa brings over all the old NeXT applications easily and provides a very attractive way to develop Mac applications, especially for small developers. Java brings in a whole other audience as well. None of these APIs are going to go anywhere, and none of them are being neglected. In fact, Apple has been hard at work unifying them over CoreFoundation. Cocoa and Carbon and C and C++ and Objective-C can be commingled freely, and Python and Java and AppleScript can talk to them and be linked to them. This integration is getting tighter and more complete with every release. There's no need for anything new; if something new comes along (Microsoft's .NET?) it can be built on top of the same Foundation that the rest are, and join the party.
MS is different animal while apple is a lean surviver, now. so supporting two api for apple is not easy as reality is that hugh amount of support effort goes to carbon support where bigger developers demand. i am not sure how many big developers jump onto the cocoa bandwagon, but one thing that is obvious is that since the relation between apple and its developers is mutual, without big developer supports, cocoa is crippled: on the one hand, the cost to have this wonderful technology is not a non-issue anymore, if current economy situation persists; on the other hand, cocoa needs to have some serious execises in bigger apps, not just some pet app you and i create, with all due respect.
The real issue here is that the final appearance, reliability, performance and polish of an application is up to the developers, not the API (although the language and API chosen will help or hinder these goals variously — it's the developer's job to pick the most appropriate ones). Whether it's a Cocoa app, or Carbon, or Java, or RealBasic, or AppleScript Studio, or what-have-you should be completely transparent to the end user. In the end, a Mac application is a Mac application; if it isn't, the developers didn't do their jobs.
in apple's case, blames more or less reside on apple's head. let us not dig up the old shabby history how apple treated its developers as i still have my OpenDoc developer sdk and books... let us assume microsoft starts to use cocoa for their mac products. but one day, let us say 1.5 year from now, apple decided to cancel cocoa or cease its developing. what will happen? the same thing is true for carbon. apple is apple, if some one else it has been dead zillions of times already if the scenario happens.
the situation i sense now is that big developers are united and demand apple have a carbon api, which used to be thought as a transition to cocoa but now a parallel api to cocoa, for their products. developers, either microsoft or adobe, are apple's another important customers, beside the end users at apple stores or homes. maybe apple could dump all of them and have everything inhouse. in this case, i rest my case.
last, we are getting too long on the exchange. if you want to discuss further, email me.
Originally posted by anakin1992
please read the release notes from apple on its java 1.4.1 release.
I have. They were the basis for my point.
Java 1.4.1 breaks things chiefly because they didn't implement the whole thing. The fact that it's now in Cocoa is irrelevant to Java developers, except that the bridge to Cocoa is now much nicer (obviously). Pure Java developers won't notice Cocoa. They will notice the bugs and omissions in Apple's implementation of 1.4.1.
do you know any big vendor working on moving the front end, GUI part, to cocoa? also let me ask this simple: which way is easier for, any, vendor who has hugh existing carbon code base, to do: using existing carbon code to have its applications on mac os x or creating cocoa code to into face carbon code?
The least time I checked, Apple itself was a big vendor.
As for the rest, I don't know. I don't pay much attention to big vendors precisely because of issues like this. It remains to be seen if QXP6 does, since they swear up and down that it's OS X native (on the other hand, this is Quark...). Adobe has their own platform with their own interface, so I doubt they use too many native widgets anywhere.
i hope the situation, where cocoa app uses carbon which then uses cocoa, will not occur.
I don't see how it's possible.
you misuderstood my piont: customers i mentioned are not the end users, like you and me. apple's customers in developing communities are developers, both big name and small kids. of course, these "customers" will notice the hugh differences.
Maybe and maybe not. Certainly not as much as a compiler change (particularly not a gcc compiler change, since gcc has a well-established reputation for breaking things between versions).
The differences will matter most as far as interfacing closely with an application, i.e. using its scripting dictionary, or (if the developer allowed) querying the runtime for methods to hook in to or augment with categories. The events sent and received from Cocoa and from Carbon Events should be indistinguishable. If they are not now, it's because Apple hasn't finished integrating the two.
yes, end user will never notice the differences on whatever changes in the Finder. but developers notices it when they program and debug. you could argue that changes are minimal to developers too. but my concern is that what will happen to an existing application where the behaviors, event machenism changes, cause their debugging difficulties.
If the event mechanism changes, it'll change in both.
i am still using gcc 2.95 release though it is 3.2(?) already. why? changes in newer version broke hugh part of support libraries in my product code. should i work to correct those imcompatibilities? i wish i have enough capable man and money.
Yeah, gcc is famous for doing that on all platforms. It has nothing to do with Carbon or Cocoa, or OS X's event handling.
MS is different animal while apple is a lean surviver, now. so supporting two api for apple is not easy as reality is that hugh amount of support effort goes to carbon support where bigger developers demand. i am not sure how many big developers jump onto the cocoa bandwagon, but one thing that is obvious is that since the relation between apple and its developers is mutual, without big developer supports, cocoa is crippled: on the one hand, the cost to have this wonderful technology is not a non-issue anymore, if current economy situation persists; on the other hand, cocoa needs to have some serious execises in bigger apps, not just some pet app you and i create, with all due respect.
First, while the big Mac developers are important, they are far from the whole story. Apple is jumping on the Cocoa wagon with both feet: Abandoning Cocoa even at this early point would mean porting a whole slew of their own apps back to Carbon, with the attendant increases in bugs, programmers required and time taken. They seem to be doing all new development in Cocoa exclusively, and I can't blame them.
Second, there is the whole halo of Cocoa apps, many of which are not as visible as Photoshop but which are no less important for that, which would get cut out. Cocoa has enterprise cred.
Lastly, Cocoa is Apple's carrot to entice new development (and, as above, Apple themselves are doing new development in Cocoa. Take it away, and programming for OS X becomes that much less appetizing. Oh, and both Project Builder and Interface Builder (Cocoa apps long since) break, and have to be rewritten with, again, more programmers, more time, more lines of code, etc.
Apple is not abandoning either Carbon or Cocoa. It's not happening. I think you're overstating this issue dramatically.
let us assume microsoft starts to use cocoa for their mac products. but one day, let us say 1.5 year from now, apple decided to cancel cocoa or cease its developing. what will happen? the same thing is true for carbon. apple is apple, if some one else it has been dead zillions of times already if the scenario happens.
But if Apple uses it, what happens?
the situation i sense now is that big developers are united and demand apple have a carbon api, which used to be thought as a transition to cocoa but now a parallel api to cocoa, for their products. developers, either microsoft or adobe, are apple's another important customers, beside the end users at apple stores or homes. maybe apple could dump all of them and have everything inhouse. in this case, i rest my case.
last, we are getting too long on the exchange. if you want to discuss further, email me.
Carbon was always pitched as a permanent API. It was pitched as a transition API from OS 9 to OS X, not from Carbon to Cocoa.
I'll answer here, because this is an interesting issue, and I'd be interested in input from the other developers here.
Features discussed in the article:
[list=1][*]"User at the Center features will make it simpler for individual users to personalize their computing experience and to move seamlessly among Macs and other devices."[*]Fast user switching[*]Piles[*]"Panther will add more database-like structures to the file system, although the underlying file system will remain HFS+, ensuring backward compatibility."[*]Improved I/O performance [*]"Sources also said Apple will provide full 64-bit support in Panther."[/list=1]
All in all, nothing that hasn't been discussed ad infinitum at these boards. We'll see how reliable their "source" is when Panther ships I guess...
Originally posted by NETROMac
More Phanter info from eWeek
Mac OS X ElePhanter.
Originally posted by NETROMac
"User at the Center features will make it simpler for individual users to personalize their computing experience and to move seamlessly among Macs and other devices."
One thing this does point to is a specific concept that's fueling, directing development. The article seems a bit short on more such features, but as you said, many if not most have been discussed here already. The reported "metal" theme, or more flexible appearances in general, possibly more work done to the directory layout or rather some abstraction of it to feel more personalized, smart folders and piles, etc are all ideas that fit this agenda. Am I missing any?
"Panther will add more database-like structures to the file system, although the underlying file system will remain HFS+, ensuring backward compatibility."
This is more like what I was expecting than a new FS altogether. This was the talk after the journaling plugin was introduced to HFS+ so why not other stuff too?
Originally posted by BuonRotto
This is more like what I was expecting than a new FS altogether. This was the talk after the journaling plugin was introduced to HFS+ so why not other stuff too?
One question: Are there any limitations or problems with taking this approach instead of making a new file system from "scratch"?
Pros:
- Backwards compatibility
- Tried and tested file system
- Possible to update file system w/o (re)formatting.
Cons:
- Speed hit
- Difficulties to implement new features
- Long development time?
- Limitations in architecture?
New list then
Pros:
- Backwards compatibility
- Tried and tested file system
- Possible to update file system w/o (re)formatting.
- Faster development
Cons:
- Speed hit
- Difficulties to implement new features
- Limitations in architecture?
Originally posted by NETROMac
BuonRotto - thanks for replying...
New list then
Pros:
- Backwards compatibility
- Tried and tested file system
- Possible to update file system w/o (re)formatting.
- Faster development
Cons:
- Speed hit
- Difficulties to implement new features
- Limitations in architecture?
The last two cons are addressed by Apple's choice of VFS (virtual file system) as the logical filesystem. VFS has a plug-in architecture, so you could, for example, write plug-ins to PGP-encrypt every file as it was saved, and unencrypt it as it was opened, and no application would be the wiser.
Applications use VFS. HFS+ just happens to be the underlying actual filesystem. But because of VFS and its architecture, you can put all kinds of nifty things between the applications and the filesystem, without requiring reformats or modifications to code.
There is a speed hit, however.
Stacking File Systems -- Apple does not support the development of stacking VFS plug-ins on Mac OS X. We've taken this position because, in our opinion, it's not possible to create a stacking VFS plug-in that:[list=1][*]works reliably,[*]does not severely impinge on system performance, and[*]has any hope of binary (or even source-level) compatibility with future systems.[/list=1] Earlier Apple documentation stated that stacking VFS plug-ins could be used to solve certain problems, such as file-level encryption and virus checking. We even went so far as to publish an example of this, the Politically Correct file system (PCFS), that ran on pre-release builds of Mac OS X. Subsequent experience has shown that this technique does not work properly and we no longer support it. Thus, we have removed (or soon will) all references to stacking VFS from our documentation and we will not publish an update to PCFS. The existing PCFS source code is not useful because it has not been updated to support the Unified Buffer Cache.
Interesting... is this in any way contradicting your post Amorph?
Does this in any way imply that we'll get a new FS
Deep inside Apple's Piles
Here is some information frome the article on how different browsing methods could be implemented.
Even a glance at Apple's HIG 1992 paper shows a thoroughness and inquisitiveness that's lackingin much of today's software. Rather than being contented with the Pile, the team was weighing pros and cones of how it should behave, using iterative user feedback. For example, the researchers identified four kinds of browsing methods: an "edge" method where users looked for clues from the outlines of documents in the stack; a "restack" method, where users took documents off the top to reveal the next; a "hinge" method, which sounds very much like leafing through a book, stopping at various points, and a "spread" method which empties the contents of the pile on the floor, so to speak. They explored the optimal structure of a Pile viewing "Cone".
Originally posted by NETROMac
From ADC:
Interesting... is this in any way contradicting your post Amorph?
It certainly appears to contradict my post. Bummer.
I was looking forward to the Politically Correct File System.
Does this in any way imply that we'll get a new FS
If so, it'd better be able to look a whole lot like HFS+, or all kinds of stuff will break.
Originally posted by Amorph
It certainly appears to contradict my post. Bummer.
I was looking forward to the Politically Correct File System.
If so, it'd better be able to look a whole lot like HFS+, or all kinds of stuff will break.
Yupp. But they have the code for HFS+ (I guess), so they could just add new features to the current codebase. Expand the FS from inside in a way
Furthermore, it looks like some screenshots of Panther have been leaked:
Panther Desktop
let the debunking begin
low-fi
[edit by Amorph: Changed desktop image to link to restore board formatting.]
Originally posted by NETROMac
FAKE!!!
But you gotta dig that darker blue 'X' !
Apple-X Exclusive: Be the first on your block to see what could be the first leaked Panther screen-shots!
We received a little surprise in our e-mail tonight containing two screen shots suspected of coming from Mac OS 10.3; code-named Panther. According to our source the images are from an early build of 10.3, build 7D15. With to the trained eye, I personally could not find any flaws in the screen-shots. What I did notice is that the Mac OS X logo and Apple logo in the right hand corner appear to be darker. The highlight color is also darker but this can easily be changed in any current version of OS X. Another interesting thing to note is the addition of a new item in the "default" dock which is a sample application from developer-tools with an icon featuring a compass (Not like the Safari icon but the thing you make circles with.) and what looks like a blueprint. The dock also appears to be slightly more transparent and lastly the hard drive icon has a green light on it compared to the yellow light found on Jaguar OS X icons. While it is not known wether or not these images are real, I guess we will just have to wait and see if we receive cease-and-desist order, thus proving validity of the images. So for now I leave the decision to you.