or Connect
AppleInsider › Forums › Software › Mac OS X › Collection of *confirmed* Panther info.
New Posts  All Forums:Forum Nav:

Collection of *confirmed* Panther info. - Page 2

post #41 of 228
Quote:
Originally posted by anakin1992
many thanks for the info. i only knew couple of them. one example makes me quite wonder: if i have an old java application on java 1.3, now in order to use java 1.4, do i have to rework my application to fit java 1.4? normally, i would continue to use java 1.3. but the problem occurs when apple will only update on java 1.4 on bug fix or new features, then i have to be forced to do things in java 1.4. it is ok for once to do it. what about sometime later apple finds a new way to do java on mac os x, what am i going to do again?

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.

Quote:
yeah, it makes much sense to have complete new application in cocoa. by new, i meant, no reuse on the old code. not just for apple, every one else should use cocoa for new app. but the question remains: are those old apps, such as word, excell, ps, etc to be written in cocoa or not? another interesting question will be: are there any new apps that are going to replace those old apps in carbon, such as word, etc?

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.

In fact, any Cocoa app that deals with QuickTime is going to have a healthy amount of Carbon code in it.

Quote:
i am not against using cocoa or carbon, as long as it works, i am fine. but what do customers think? if new Finder in panther is cooked in cocoa, what are the effects this change will bring to the behaviors on the interaction between the Finder and application?

Ideally, the customers shouldn't notice. The decision to use an API should be a development decision. In practice, Cocoa allows a few developers to write a very slick application with comparatively few lines of code, so Cocoa apps are often considered more polished just because apps get all that behavior for next to nothing. This is not intrinsic, of course, because Mac OS Toolbox apps achieved high levels of polish despite being on an API more primitive than Carbon — it just required a lot of elbow grease to get there.

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.

(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.)

Quote:
the only ways i think of that apple will be ok are that there will be a new technology, either hardware or software, rendering both carbon and cocoa as usless or at least not efficient any more; or, apple decides to dump all the old buddies, like adobe, microsoft, etc and dose every thing by itself.

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.

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.
"...within intervention's distance of the embassy." - CvB

Original music:
The Mayflies - Black earth Americana. Now on iTMS!
Becca Sutlive - Iowa Fried Rock 'n Roll - now on iTMS!
Reply
"...within intervention's distance of the embassy." - CvB

Original music:
The Mayflies - Black earth Americana. Now on iTMS!
Becca Sutlive - Iowa Fried Rock 'n Roll - now on iTMS!
Reply
post #42 of 228
Quote:
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.

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.
post #43 of 228
Quote:
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.

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.
"...within intervention's distance of the embassy." - CvB

Original music:
The Mayflies - Black earth Americana. Now on iTMS!
Becca Sutlive - Iowa Fried Rock 'n Roll - now on iTMS!
Reply
"...within intervention's distance of the embassy." - CvB

Original music:
The Mayflies - Black earth Americana. Now on iTMS!
Becca Sutlive - Iowa Fried Rock 'n Roll - now on iTMS!
Reply
post #44 of 228
More Panther info from eWeek
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...
Former WWDC Watchdog.
Reply
Former WWDC Watchdog.
Reply
post #45 of 228
Quote:
Originally posted by NETROMac
More Phanter info from eWeek

Mac OS X ElePhanter.
JLL

95% percent of the boat is owned by Microsoft, but the 5% Apple controls happens to be the rudder!
Reply
JLL

95% percent of the boat is owned by Microsoft, but the 5% Apple controls happens to be the rudder!
Reply
post #46 of 228
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?
post #47 of 228
Quote:
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?
Former WWDC Watchdog.
Reply
Former WWDC Watchdog.
Reply
post #48 of 228
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.
post #49 of 228
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?
Former WWDC Watchdog.
Reply
Former WWDC Watchdog.
Reply
post #50 of 228
Quote:
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.
"...within intervention's distance of the embassy." - CvB

Original music:
The Mayflies - Black earth Americana. Now on iTMS!
Becca Sutlive - Iowa Fried Rock 'n Roll - now on iTMS!
Reply
"...within intervention's distance of the embassy." - CvB

Original music:
The Mayflies - Black earth Americana. Now on iTMS!
Becca Sutlive - Iowa Fried Rock 'n Roll - now on iTMS!
Reply
post #51 of 228
From ADC:
Quote:
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
Former WWDC Watchdog.
Reply
Former WWDC Watchdog.
Reply
post #52 of 228
Little bit on 'Piles' from El Reg:

Deep inside Apple's Piles
post #53 of 228
Interesting article naderby.

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".
Former WWDC Watchdog.
Reply
Former WWDC Watchdog.
Reply
post #54 of 228
Quote:
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.

Quote:
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.
"...within intervention's distance of the embassy." - CvB

Original music:
The Mayflies - Black earth Americana. Now on iTMS!
Becca Sutlive - Iowa Fried Rock 'n Roll - now on iTMS!
Reply
"...within intervention's distance of the embassy." - CvB

Original music:
The Mayflies - Black earth Americana. Now on iTMS!
Becca Sutlive - Iowa Fried Rock 'n Roll - now on iTMS!
Reply
post #55 of 228
Quote:
Originally posted by Amorph
It certainly appears to contradict my post. Bummer.


Quote:
I was looking forward to the Politically Correct File System.


Quote:
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
Former WWDC Watchdog.
Reply
Former WWDC Watchdog.
Reply
post #56 of 228
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?
post #57 of 228
I have the original conference paper that piles were introduced in if anyone would like to read it.

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.]
post #58 of 228
FAKE!!!
Former WWDC Watchdog.
Reply
Former WWDC Watchdog.
Reply
post #59 of 228
Quote:
Originally posted by NETROMac
FAKE!!!

But you gotta dig that darker blue 'X' !
post #60 of 228
Here's the article text:
Quote:
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.
Former WWDC Watchdog.
Reply
Former WWDC Watchdog.
Reply
post #61 of 228
Can the formatting of this thread be skinnier for us 12" powerbook and iBook users?
"Overpopulation and climate change are serious shit." Gilsch
"I was really curious how they had managed such fine granularity of alienation." addabox
Reply
"Overpopulation and climate change are serious shit." Gilsch
"I was really curious how they had managed such fine granularity of alienation." addabox
Reply
post #62 of 228
Well, if it is fake, it's been done well. The Apple Menu 'apple' and the logo also match perfectly.
post #63 of 228
here's the fun part! Some little details make it more credible, tohugh obviosly I take all this stuff with a grain of salt. The pile on the desktop looks wonky with how they truly look "tossed" onto one another. Looks like it's just a bunch of text clippings. The icon with the compass and bleprint is Sketch.app. I've always liked that icon a lot, maybe they've found a better use for it (yeah, right). The consolidate item is interesting.... I could go either way on that thing.
post #64 of 228
Quote:
Originally posted by BuonRotto
The consolidate item is interesting.... I could go either way on that thing.

So what would be 'consolidated'? The 'pile'? What would 'consolidating a pile' do?

Sounds painful!
post #65 of 228
yeah, it IS sketch.app from the developer tools..

that consildate thing is a little...iffy

well, it seems to be real, but who knows, it is easier to fake a screen shot than it is hardware
post #66 of 228
More about Panther, this time from macosXrumors :

Quote:
Panther part 2: new versions of iAppz, new features on system appz, final Safari, exit Explorer. UPDATED!

UPDATE: Some sites recently revealed a feature called piles that is maybe the same feature my sources were mentioning when they told me about new navigation features on Panther. Our friends of Apple-X.net have two screenshots of what they call build 7D15 of Panther. The first shows the "New Pile" item of the File menu and the second shows how will a pile will look like. We can't be sure if it's real screenshots of Panther or not but it's interesting to have an idea of what we may see on Panther.

For this second part of my article dedicated on Panther, I've questioned my sources on features that we'll find on new versions of the system applications and iAppz that are going to be included with Mac OS X Panther.

- As we can guess, a final version of Safari will be released with Panther. Some sources told me that Internet Explorer would definitely be ousted from Mac OS X.
- New release of iTunes should come separately very soon. Note that it is something I have already reported on an article posted on March the 14th and it looks like it is more and more confirmed. The new version of iTunes will of course also be included in Panther.
- Sherlock will probably be improved again with channels loading faster, better .Mac integration and online ordering capabilities.
- Mail is also said to get new features with a major update (I couldn't get further details).
- A new version of iSync, if it doesn't come separately, will come with Panther. This version will add compatibility with several devices and improve .Mac synchronizing (synchronizing of Safari bookmarks has been mentioned).
- iCal will also be updated with minor changes to the GUI and new features of which I couldn't get details.
- Disc burning will probably get some new features. Some sources mentioned the possibility of burning ISO 9660 volumes and better support for data-DVD burning. It is also possible that Apple is planning a more user friendly GUI for this application but I couldn't get confirmation from reliable sources about that.
- Address Book will add, according to some new sources, advanced export features that will allow you to make lists of contacts to print or to publish.
- An improved version of iChat is also expected. Some sources mentioned video-conferencing capabilities, support for other networks and possibility to send SMS (via Bluetooth and/or .Mac).
- QuickTime is going to be updated and may finally fix some bugs for the popular DivX codec (actually with .avi files) but will not necessarily include it in this new version. It is also possible that the full screen feature will become available to non-registered users. Actually it looks like one of the reasons why QuickTime partially lost its popularity is the fact that the full screen feature is not present on the free player. It is not sure whether it will be numbered 6.5 or, as some sources mentioned, "version 6.2".
- Apple will certainly add Rendezvous related features to many of its applications and even better integration between them.
- As with Jaguar, most of the iApps' updates will be also made available for free download but I guess that there will be some surprises that no rumour site will have mentioned - like it happens on every major upgrade to Mac OS.

It is possible that Apple releases new iApps with Panther but at the moment I don't have any reliable information on that subject. I believe that, once again, it will be quite worthwhile purchasing this upgrade to Mac OS X. For those who have been Mac OS X users since the beginning and believe that it's getting too expensive to pay each year for upgrades to an operating system that started becoming mature only lately, I'd suggest you compare all the money you have spent for Mac OS X since its release with the price of Windows XP. I don't know if there will be a "part 3" article on Panther but be sure that if I get further interesting news, you'll be informed as soon as it is properly verified. So stay tuned and those who can help me, it's here! Note to some quite awkward readers: sending me questions using the anonymous form has no sense as I won't be able to answer to you .
Former WWDC Watchdog.
Reply
Former WWDC Watchdog.
Reply
post #67 of 228
Quote:
- A new version of iSync, if it doesn't come separately, will come with Panther. This version will add compatibility with several devices and improve .Mac synchronizing (synchronizing of Safari bookmarks has been mentioned).

Safari thinks its doing this already. Sometimes when I try to save a bookmark with beta 2, it tells me it can't because iSync is using the bookmarks file. If I just click "OK" then try to save the bookmark again, it's OK. It's probably a bug, but it obviously thinks it's getting all iSynced up.
post #68 of 228
BuonRotto,

Safari is trying to sync something. I have been trying to use Daylite, a CRM app made for OS X. This app does not use the Addressbook as the central repository. Instead, it tries to sync with the addressbook. This is the crash I keep getting when it tries to do this.

"2003-04-06 20:19:32.264 Address Book[562] ABAddressBook could not aquireLock: 1: 'Framework/AddressBook/ABAddressBook.m'\t\tline: 1448
2003-04-06 20:19:32.264 Safari[519] ABAddressBook could not aquireLock: 1: 'Framework/AddressBook/ABAddressBook.m'\t\tline: 2287
2003-04-06 20:19:32.288 SystemUIServer[429] ABAddressBook could not aquireLock: 1: 'Framework/AddressBook/ABAddressBook.m'\t\tline: 2287"

Notice the Safari reference. I believe I sent Daylite a post that you made similar to your last about Safari and the bookmarks. I use iSync over .mac to sync my AddressBook. This creates a duplicate/new file for your addresses, etc. Daylite appears to be trying to sync with the original file vs. the duplicate/new file that iSync creates. Something is going on here that may possibly come to light in the next version of iSync.
iPad2 16 GB Wifi

Who is worse? A TROLL or a person that feeds & quotes a TROLL? You're both idiots.....
Reply
iPad2 16 GB Wifi

Who is worse? A TROLL or a person that feeds & quotes a TROLL? You're both idiots.....
Reply
post #69 of 228
Quote:
Originally posted by kcmac
Notice the Safari reference. I believe I sent Daylite a post that you made similar to your last about Safari and the bookmarks. I use iSync over .mac to sync my AddressBook. This creates a duplicate/new file for your addresses, etc. Daylite appears to be trying to sync with the original file vs. the duplicate/new file that iSync creates. Something is going on here that may possibly come to light in the next version of iSync.

Safari uses AddressBook for AutoFill.
JLL

95% percent of the boat is owned by Microsoft, but the 5% Apple controls happens to be the rudder!
Reply
JLL

95% percent of the boat is owned by Microsoft, but the 5% Apple controls happens to be the rudder!
Reply
post #70 of 228
That makes sense. Thanks.
iPad2 16 GB Wifi

Who is worse? A TROLL or a person that feeds & quotes a TROLL? You're both idiots.....
Reply
iPad2 16 GB Wifi

Who is worse? A TROLL or a person that feeds & quotes a TROLL? You're both idiots.....
Reply
post #71 of 228
Why not? Because Cocoa is Objective-C and therefore inefficient, incompatible with every other platform, almost impossible to interface to, doesn't link with C or any other language, uses vast numbers of incomprehensible "frameworks", uses an object-oriented methodology that's unlike everyone else's...

In other words, the only reasons for using Cocoa are marketing ones. The reasons for not using Cocoa are technological. Which is a more valid reason for selecting a programming API?

Mac OS X is based on Unix. Unix is a portable operating system for portable applications. Cocoa isn't portable.

[ edit by Amorph: ACK! I meant to reply, and I clicked edit! I'm really sorry about that. I restored what I could. Mea maxima culpa ]
post #72 of 228
Quote:
Originally posted by cubist
Mac OS X is based on Unix. Unix is a portable operating system for portable applications. Cocoa isn't portable.

I thought Cocoa could have C and C++ code wrapped into its ObjC classes, essentially reskinning (IB) the app in question? Actually, Cocoa is portable, just that Apple hasn't ported it. Maybe at some point when a critical mass or mass appeal has been reached, Apple will do ust that. Just speculatin' though. This is a very important reason why we have Carbon/CoreFoundation no matter what.
post #73 of 228
Quote:
Originally posted by cubist
Why not? Because Cocoa is Objective-C and therefore inefficient, incompatible with every other platform, almost impossible to interface to, doesn't link with C or any other language, uses vast numbers of incomprehensible "frameworks", uses an object-oriented methodology that's unlike everyone else's...

Thats funny, I am able to link to C and C++. In fact, Objective-C is a small superset of C. You can use C and C++ code intermingled with Objective-C code. Objective-C itself is available on other platforms. You are correct that Apple currently does not provide the Cocoa frameworks on any other platforms. There is however GNUStep, which is a close replica. As far as vast number of frameworks, in Cocoa there are 2, Foundation and the AppKit. Also, they are not very large even though they have a rich feature set. You must not have ever done any Java either. Probably not C++, but I am not qualified to address the various libraries used in that language, although I am pretty sure there are more than 2.

What is the "Objective-C Methodogy"? Objective-C itself does not provide any methodology. You can use any you want. Objective-C tends to promote using an Object Oriented Methodology, because, well, it uses objects. What methodology are you referring to? It is dynamic, perhaps that is what is throwing you off. Going from Java to Objective-C is pretty easy. Now if you are not familiar with Object Oriented Concepts, the step from C can be somewhat steep, but only because of the concepts. It took me a few hours for the syntax and about a week to be confortable with the Object Oriented Paradigm.

As far as efficiency, you must be referring to runtime efficiency, not programmer efficiency. You are correct that it is slower that pure C, or C++, but that is due to the dynamic dispatching of messages at run time, which allows you to do all sorts of neat things that are not possible, or are extremely difficult, in languages like C and C++, where there is a static mapping to a function symbol at compile time. If pure performance is needed in Objective-C, you can use C or C++ for those small sets of code. However, the runtime itself is actually very efficient and performance issues are mostly due to programming issues, not language or runtime issues.

Finally, interfacing to the Cocoa frameworks is not difficult. It can be done and Apple actually has some pointers. It is down-right ease to do with Java (gets many of its concepts and ideas from Obj-C), Python, Perl, and Ruby. There may be others that have the link already set up for you, but I am unsure. You may be correct about calling Objective-C from C++ (not the other way around). This is due to the static nature of C++ and its inability to handle the dynamic nature of Objective-C. As mentioned earlier, it is trivial to call C++ from Obj-C.
post #74 of 228
Quote:
Originally posted by Amorph
If so, it'd better be able to look a whole lot like HFS+, or all kinds of stuff will break.

Or go with a new file system and use a VFS plugin to provide HFS+ compatability?

Radical for Apple I know...
post #75 of 228
Quote:
Originally posted by David M
Or go with a new file system and use a VFS plugin to provide HFS+ compatability?

Radical for Apple I know...

Would still break lots of old apps.
post #76 of 228
LoopRumors will supposedly post more information about panther tomorrow morning.
Quote:
LoopRumors has gathere and will post details of Mac OS X Panther tomorrow morning. Stay tuned.

Exxxxiting...
Former WWDC Watchdog.
Reply
Former WWDC Watchdog.
Reply
post #77 of 228
Thread Starter 
Quote:
Originally posted by NETROMac
Exxxxiting...

Well I won't lose any sleep about it. But fresh info would be nice (something other then more pile info.
I never get tired of being right all the time... but I do get tired of having to prove it to you again and again.
Reply
I never get tired of being right all the time... but I do get tired of having to prove it to you again and again.
Reply
post #78 of 228
Well, here it is:

Quote:
Mac OS X Panther details

Originally scheduled for May 19-23 in San Jose, the 2003 Worldwide Developers Conference (WWDC) will now be held June 23-27 at San Francisco's Moscone Center. Apple made this change in order to prepare for the next version of its Macintosh operating system, code named "Panther." Panther will mark the third significant upgrade to Mac OS X since its debut. LoopRumors has been hard at work gathering information about the upcoming feline. Here's what we've learned:

System-wide metal. Panther's applications system-wide will sport a metal interface. When LoopRumors first reported a system-wide metal interface on March 18th, it was misinterpreted throughout Macintosh sites all over the net. Most applications already support the metal theme.

Flatter Aqua. The overall Aqua appearance in Panther will be flatter with less dimension. The last iChat update late last year showed signs in this direction with the red yellow and green window controls flatter, appearing more recessed within the window. The recently released iTunes also shows signs with the flatter play, fast forward and rewind buttons.

Improved Dock. You will now be able to control document windows that are sent to the dock. Click and hold on the window's icon in the Dock to Save, Print or Close that window.

Piles. Piles will work just like piles of paper stacked up on your desk. Instead of documents having their own individual space on your computer, you group them together in a Pile and see the contents of that Pile by clicking on it.

iChat 2.0. As we reported on December 5th with a subsequent report on March 24th, iChat will be Apple's answer to Microsoft's NetMeeting. iChat 2.0 will support videoconferencing with video streams at broadcast quality 30fps, taking advantage of a new compression that Apple has been developing. Other new features will include information on how long a buddy has been signed on and access to member profiles.

Safari 1.0. The Safari web browser will be included as a golden master. Information on new features is still varied, we'll have more on this soon.

iWorks. Apple is developing a new software package that will rival Microsoft's Office X. On March 15, 2003, ThinkSecret first reported that Apple was working on a new productivity suite. iWorks will consist of a word processing application tentatively called "Document," Apple's Keynote presentation software, a spreadsheet/database application, and an updated Mail 2.0 app.

Advanced Mouse Support Built-in. Support for most third party mice with two and three buttons built in. Jaguar already contains support for scroll wheel mice. On April 30th, LoopRumors reported on a Bluetooth mouse in the works. We stand by this report.

Advanced Software Update. Several sources indicate that the Software Update Control Panel is redesigned. One report specifies that SUCP will maintain a history of all purchases made through one-click, i.e. iTunes Music and software purchased through the Apple Store, will always be accessible for download through that User ID.

64-Bit Support. Panther is written to take full advantage of 64-Bit architecture. Further evidence that Apple will adopt IBM's new PowerPC 970 chip. Although most Application written at the time of release will only be optimized for 32-Bit.

We are still making sense of some of the information we were given. Stay tuned for more information on Panther available on LoopRumors in the next few days.

And there's only

left
Former WWDC Watchdog.
Reply
Former WWDC Watchdog.
Reply
post #79 of 228
So they are fiddling once more with Aqua.

I wonder if all the buttons will gain the new 'recessed' look?
post #80 of 228
It would not be very good if altering windows background had a higher priority than metadata file system on Apple's to-do list. All in all, this report looks very suspicious to me.
Quote:
iWorks will consist of a word processing application tentatively called "Document," Apple's Keynote presentation software, a spreadsheet/database application, and an updated Mail 2.0 app

So you make a document in Document, select it in Finder, Get Info and see 'Document document'?
Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand. Putts Law
Reply
Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand. Putts Law
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Mac OS X
AppleInsider › Forums › Software › Mac OS X › Collection of *confirmed* Panther info.