[clarkgoble]

Mac rumors notes that there is a book coming out that appears to be for an unreleased version of Appleworks.

http://www.macrumors.com/pages/2004/...04120830.shtml

Pretty good news if true. People have been waiting for a *real* OSX version of Appleworks for years. The version out at the moment still is very Classicish in many ways and doesn't take advantage of many OSX features. (Plus it sucks in certain other ways)

Here's hoping.

[Millennium]

I wouldn't get my hopes up if I were you. Apple has been dragging its feet for three years now, and I don't expect them to change that behavior pattern.

All the same, it would be wonderful to see an update of AppleWorks. In fact, I'd love to see an update done completely in Carbon, as proof that a Carbon app can be every bit as good as a Cocoa one. AppleWorks was the app which first gave Carbon a bad name, and it can be the app to restore its reputation.

Mind you, I also think that Apple made a big mistake writing the Finder in Carbon in the 10.0 days: eating one's own dogfood is important, but they should have done that by pouring developer effort into AppleWorks and simply keeping the Cocoa-based Finder (nee Workspace Manager) from Rhapsody. That way we'd have had a good Finder and a good AppleWorks from the very beginning, plus Carbon's viability would have been proven. As it was we got the original Bad Carbon Port in AppleWorks, and 10.0's Finder was a disgrace.

[clarkgoble]

The difference is that for a book on the upcoming Appleworks to be written, the author would have to have some knowledge of the general release time as well as have betas and be working with the development team. That suggests that the product is in some level of maturity.

[Millennium]

Originally posted by clarkgoble:
The difference is that for a book on the upcoming Appleworks to be written, the author would have to have some knowledge of the general release time as well as have betas and be working with the development team. That suggests that the product is in some level of maturity.

The other possibility is that there's a mistake in the title on the site you mention.

[Krypton]

Originally posted by Millennium:
The other possibility is that there's a mistake in the title on the site you mention.

Exactly, it is far more likely Apple will let AppleWorks disappear. However, now would be a good time for a release: i.e. after Office 2004 is out.

[Horsepoo!!!]

Originally posted by Millennium:
I wouldn't get my hopes up if I were you. Apple has been dragging its feet for three years now, and I don't expect them to change that behavior pattern.

All the same, it would be wonderful to see an update of AppleWorks. In fact, I'd love to see an update done completely in Carbon, as proof that a Carbon app can be every bit as good as a Cocoa one. AppleWorks was the app which first gave Carbon a bad name, and it can be the app to restore its reputation.

Mind you, I also think that Apple made a big mistake writing the Finder in Carbon in the 10.0 days: eating one's own dogfood is important, but they should have done that by pouring developer effort into AppleWorks and simply keeping the Cocoa-based Finder (nee Workspace Manager) from Rhapsody. That way we'd have had a good Finder and a good AppleWorks from the very beginning, plus Carbon's viability would have been proven. As it was we got the original Bad Carbon Port in AppleWorks, and 10.0's Finder was a disgrace.

No...I've had enough of 'Apple eating its own food' bullcrap. A Carbon rewrite would most likely be more time consuming that writing a Cocoa app. I couldn't care less about Carbon's reputation. And if rumors are true that the end-user shouldn't know or care what framework has been used, then why not make it a Cocoa rewrite.

[hmurchison2001]

Ok it's time not to be jaded about this. Everthing points to this being totally legit.


Title: AppleWorks 6 for Macintosh : Visual QuickStart Guide
ISBN: 0201702827
Author: Nolan Hester
Format: Paperback / 2ND July 2000

This is for Nolan Hester's first AW6 book.

Here's the new book

Author: Nolan Hester
ISBN: 0321246640
Publisher: Peachpit Press - March 2004
Format: Paperback

Seems clear cut to me. Date differs by 4 years and ISBN number is different. We gotta ask ourselves why would PP take 4 years and register a new ISBN for AW 6.2.9. Answer is they wouldn't. This is a new version coming that is substantial enough to warrant the need of a new updated book. That in my book is AW7.

[gorickey]

I hope it's true...

[Krypton]

The question is, would it be a complete rewrite (yay!) or just enough to ensure it doesn't suck anymore?

[Rev-O]

I would be wonderful if Apple would finally bring Appleworks up to speed. I'd buy it in a heartbeat. But, seeing as how Appleworks seems to be the red-headed stepchild of the Apple software empire, I'm not holding my breath.

[Cadaver]

Originally posted by Krypton:
The question is, would it be a complete rewrite (yay!) or just enough to ensure it doesn't suck anymore?

Wouldn't these two statements have to be equivalent?
The only way to make AppleWorks not suck anymore is to do a complete rewrite.

[lookmark]

Finally. At least one can hope.

I don't think Apple has been letting AppleWorks die on the vine for no reason at all. The question (and, one suspects, internal struggle) has always been whether Apple should challenge MS Office in the professional Office space in a full-blown assault... or do the consumer Office (n-Works) thing, and take it from there. It looks like -- if this right -- they're doing the latter. I think it's the right move.

[MPMoriarty]

I think it is important to keep AppleWorks alive. It has a lot of potential. What I feel Apple should do is continue to improve AppleWorks but also work on a Office-killer on the side and release the components one by one. They have already did this with keynote, filemaker is a good equivalent to access, now they just need to work on a good word processor.

Forget trying to make an Outlook/Entourage app. I think Mail is extremely powerful and flexible. And with its strong support and integration with address book and iCal, it is a killer suite. What is needed that I think Apple should release if they intend to create an office style application suite is an app to tie Mail, Address Book, and iCal together.

Something similar to CRM4Mac...

http://www.crm4mac.com/

Just my two cents.

Mike

[timothyh]

Hi all.
Getting back to the original post...
Much as I lay awake at night imagining life with AW7 (no, really!), googling a bit deeper reveals that Hester's new book is for all versions of Appleworks. As in OSX.3.x for all versions of Panther. Sorry. But you, ahem, knew this already, of course...

[Krypton]

Originally posted by timothyh:
Hi all.
Getting back to the original post...
Much as I lay awake at night imagining life with AW7 (no, really!), googling a bit deeper reveals that Hester's new book is for all versions of Appleworks. As in OSX.3.x for all versions of Panther. Sorry. But you, ahem, knew this already, of course...

Blasphemy!!! Oh well, AppleWorks sucky forever!

[Millennium]

Originally posted by Horsepoo!!!:
No...I've had enough of 'Apple eating its own food' bullcrap. A Carbon rewrite would most likely be more time consuming that writing a Cocoa app.

OK, that's so wrong I don't even know where to begin. And even if a rewrite were to take less time in terms of writing the code, it would take significantly more time to test all that new code. You don't just throw out a codebase without very good reason,

I couldn't care less about Carbon's reputation.

If you care at all about the Mac then you should, because Carbon is what the big-name developers are using. This is not to say it's better than Cocoa -it's not; they're just two different APIs and to compare one to the other is ridiculous- but the reality is that it's being used, and it's good for its developers to be confident in it.

And if rumors are true that the end-user shouldn't know or care what framework has been used, then why not make it a Cocoa rewrite.

The end-user shouldn't know or care, but developers certainly do. The biggest problem Apple has had developer-wise recently is that people aren't confident in the Carbon APIs, largely because of Apple's own blunders.

I know, I know; blind Cocoa-zealotry is tempting. I used to be a Cocoa-zealot myself, way back in The Day. But the fact is, to people who know what they're talking about, APIs are APIs, and it's not suitable to call one "better" or "worse" than another except in the most extreme cases. Carbon/Cocoa is not an extreme case by any stretch of the imagination.

[tooki]

Besides, Carbon and Cocoa aren't mutually exclusive: an OS X app can mix and match. (Only if OS 9 compatibility is desired must pure Carbon be used.)

tooki

[Krypton]

Originally posted by Millennium:
I know, I know; blind Cocoa-zealotry is tempting. I used to be a Cocoa-zealot myself, way back in The Day. But the fact is, to people who know what they're talking about, APIs are APIs, and it's not suitable to call one "better" or "worse" than another except in the most extreme cases. Carbon/Cocoa is not an extreme case by any stretch of the imagination.

I appreciate what you're saying, but I would like you to show me a Carbon app that has: services support, customisable toolbars, spell checking, sheets, drawers (UI bells and whistles etc) and a well thought out Mac like UI. I'm not saying Cocoa apps automatically have all these things, but from guys like the OmniGroup this is what I think people have come to expect.

[Eug Wanker]

I still don't understand all the interest from end users if it's Cocoa or Carbon. I'm more interested in what AppleWorks X will actually do.

ie. Will it not suck?

[Jonesy]

A similar thing happened before Filemaker 7 was released. Someone noticed the book on a website. It was referred to as Filemaker X then as well. A few weeks later it was announced and then released.

If you check Peachpit Press' website you will find no reference to this book even though you can find it on loads of booksellers'. I'm sure this book does refer to a new AppleWorks.

I see no reason why a major rewrite should not split AppleWorks up into separate programs, for example Keynote, "Document", etc. This is what M$ does with Office so I see no reason Apple can't change things. As long as they all integrate with each other and with Mail, Address Book and iCal as well as the iApps do then this would work well.

[Rev-O]

'tis a shame about Appleworks languishing. It could SO be a program that I'd love to use. Instead it's just an app that I use (and curse) because I refuse to buy Word.

[Truepop]

Why doesn't Apple just drop AppleWorks and work with Open Office much like they did with Konquer to make Safari?

[threestain]

I reckon they've got to be putting something together - the success they've had with keynote was only stilted due to ervyone already having office and powerpoint etc.

I think they've waited to see what Office 2004's got in terms of bells and whistles, and then made sure that Appleworks X (or whatever) has all of them and then some.

OpenOffice is good, but a bit of a behemoth. IMO

[zigzag]

Interesting. Certainly Apple can't let AW languish forever. It's conceivable that the book is just an update and has been retitled "for X" because that's easier to sell, or that they jumped the gun, but one can only speculate.

When Photoshop Elements 2 came out, an O'Reilly Missing Manual showed up on Amazon. It's still there, but they keep pushing the publishing date back. It's now October 2004, which is almost 2 years late. A long time ago, it was briefly listed on O'Reilly's site as an upcoming publication, but disappeared after a short time. I seriously doubt we'll ever see that book. Of course, in that case the software really did exist, but it demonstrates that listed books don't always get published.

I've long suspected that when Gates gave $100 million to Apple years ago, Jobs promised under the table that he wouldn't compete with Office. This has served both parties well: by supporting Macs, Microsoft deflects anti-trust criticism and makes a bit of money (while at the same time keeping Office the standard). Meanwhile, Apple gets good, standardized software without having to incur the development costs (not to mention getting the $100 million). I can't think of any other reason for Apple to let AW languish the way it has - every other application has been updated. Of course, there's no telling how long this arrangement will last - I would love to see Apple produce a competitive office suite (as long as it's compatible with Office).

[MacGorilla]

(as long as it's compatible with Office).

That's the trick, isn't it?

[threestain]

Is it really that difficult to ensure compatibility? Seeing as things that sync can do it, surely software engineers at apple can do it. Apparently they're quite talented there?

[Millennium]

Originally posted by Krypton:
I appreciate what you're saying, but I would like you to show me a Carbon app that has: services support, customisable toolbars, spell checking, sheets, drawers (UI bells and whistles etc) and a well thought out Mac like UI. I'm not saying Cocoa apps automatically have all these things, but from guys like the OmniGroup this is what I think people have come to expect.

BBEdit, perhaps?

[Millennium]

Originally posted by threestain:
Is it really that difficult to ensure compatibility?

It's as difficult as Microsoft wants to make it. And believe me, they want to make it hard; otherwise people aren't locked-in.

[Eug Wanker]

Originally posted by zigzag:
When Photoshop Elements 2 came out, an O'Reilly Missing Manual showed up on Amazon. It's still there, but they keep pushing the publishing date back. It's now October 2004, which is almost 2 years late. A long time ago, it was briefly listed on O'Reilly's site as an upcoming publication, but disappeared after a short time. I seriously doubt we'll ever see that book. Of course, in that case the software really did exist, but it demonstrates that listed books don't always get published.

I agree such a listing might mean the book is coming and is a long way off, or might not come at all. But that's not the point. I'm sure most of us couldn't care less if the book is coming or not. The point is that AppleWorks X is coming.

I wouldn't be surprised to see it in Paris, or early 2005 at the latest.

Originally posted by threestain:
Is it really that difficult to ensure compatibility?

Well, considering even Microsoft itself has problems with Office compatibility over various versions of the program, I'd say yes.

Anyways, I'd guess that AppleWorks X has significantly improved Office compatibility, but also that 100% compatibility was never an intended target. The primary goal for this app I think would have been to seriously update it so that it would suck a lot less than AppleWorks 6 did, to make it a viable basic substitute for the low end Mac user. IMO, AppleWorks 6 is really pushing it, even for the low end user.

Bundling of AppleWorks X would make for a nice start for the iMac G5 in Paris. And that's what AppleWorks is all about after all. It's not about software sales. It's about selling iMacs and iBooks.

[leperkuhn]

Originally posted by MPMoriarty:

Forget trying to make an Outlook/Entourage app. I think Mail is extremely powerful and flexible. And with its strong support and integration with address book and iCal, it is a killer suite. What is needed that I think Apple should release if they intend to create an office style application suite is an app to tie Mail, Address Book, and iCal together.

iCal, in my humble opinion, is one of the most disappointing programs. outlook 2003 e-mail might be comperable to Mail in 10.4 (smart folders in outlook 2003 rock), but iCal can't compare to the Calendar part of outlook. if entourage used the address book i'd probably be all about it.

[gorickey]

Originally posted by leperkuhn:
iCal, in my humble opinion, is one of the most disappointing programs.

Out of curiosity, why do you say that?

[threestain]

I would say that iCal is a far superior program to entourage's calendar and also outlooks one. Plus it links in so much better with mail and address book. Additionally it syncs well in my experience.

[ambush]

Originally posted by Millennium:
I wouldn't get my hopes up if I were you. Apple has been dragging its feet for three years now, and I don't expect them to change that behavior pattern.

All the same, it would be wonderful to see an update of AppleWorks. In fact, I'd love to see an update done completely in Carbon, as proof that a Carbon app can be every bit as good as a Cocoa one.

Well Apple has nothing to prove. Carbon can be good.

But why use it? There's no real point, really, now that OS 9 is 150% dead.

[ambush]

Oh and Apple has been including Word Compatibility in Cocoa Classes. I think this might mean something.

[Horsepoo!!!]

Originally posted by Millennium:
The end-user shouldn't know or care, but developers certainly do. The biggest problem Apple has had developer-wise recently is that people aren't confident in the Carbon APIs, largely because of Apple's own blunders.

Developers aren't confident in the Carbon APIs? Oh noes!

[leperkuhn]

Originally posted by gorickey:
Out of curiosity, why do you say that?

I think the drawer style interface is a huge pain. It's inconsistent with the way the rest of the computer works. In mail, when you double click a message, you don't get a drawer with the message, you get a new window.

Honestly if it didn't use a drawer I'd probably like it. On my iBook g4 with a 14" screen it is very hard to use because of it though. My desktop runs at 1280x1024 and even there it's awkward.

[leperkuhn]

Originally posted by threestain:
I would say that iCal is a far superior program to entourage's calendar and also outlooks one. Plus it links in so much better with mail and address book. Additionally it syncs well in my experience.

One of the greatest things about Outlook is how you can customize it to look pretty much however you want. Have you used the different views that it offers?

Because the to-do list is in a drawer (worst decision ever) you get about 200 pixels to look at the entire list. On the contrary, you can have the to-do list in outlook take up the whole screen, and it offers way more information than iCals version.

[threestain]

I must admit I like the drawer thingies, but you can disable them and adjust them as you want.

I haven't played around much with outlook as I really dislike the overall look, and can't be bothered to play with entourage frankly! However, it does give me a bit of a biased view!

[leperkuhn]

Originally posted by threestain:
I must admit I like the drawer thingies, but you can disable them and adjust them as you want.

I haven't played around much with outlook as I really dislike the overall look, and can't be bothered to play with entourage frankly! However, it does give me a bit of a biased view!

How can I disable the drawer?

[Eug Wanker]

Originally posted by ambush:
Oh and Apple has been including Word Compatibility in Cocoa Classes. I think this might mean something.

What do you mean? Sounds interesting. (Note, in plain English please. I'm not a developer.)

[Millennium]

Originally posted by ambush:
Well Apple has nothing to prove. Carbon can be good.

But why use it? There's no real point, really, now that OS 9 is 150% dead.

It still has its uses. In particular, the fact that it is much easier to port code from just about every other API in existence to Carbon than it is to port that same code to Cocoa. This isn't just an Objective-C versus C++ issue either; the design philosophies behind Cocoa are very different from many other operating systems. A basic example can be seen in how colors are defined. Most operating systems define colors based on values for Red, Green, and Blue, and sometimes an alpha channel as well. Cocoa's no different as far as that is concerned. However, most other APIs define each of these values as an integer (1, 2, 3, 10, etc.) from 0 to 255, while Cocoa defines it as a floating-point number (0.0, 0.1, 0.5, etc.) from 0 to 1. Cocoa's method is better, because it can allow for (theoretically) an infinite number of colors, including colors that current technology can't even display. However, that comes at a cost; to convert from any other system, you have to add 1 and divide by 256. This doesn't sound like an issue when you're dealing with just one color, and perhaps it isn't, but when you must deal with many thousands (such as with images) things begin to break down. It's times like this that an API which natively understands the integer values comes in handy, and that's where Carbon comes in.

Because just about every big-name developer out there has products for multiple platforms, Carbon is a worthwhile investment for them even if they have no intention of supporting OS9. Carbon isn't just about backward-compatibility, you know.

[Horsepoo!!!]

Originally posted by Millennium:
It still has its uses. In particular, the fact that it is much easier to port code from just about every other API in existence to Carbon than it is to port that same code to Cocoa. This isn't just an Objective-C versus C++ issue either; the design philosophies behind Cocoa are very different from many other operating systems. A basic example can be seen in how colors are defined. Most operating systems define colors based on values for Red, Green, and Blue, and sometimes an alpha channel as well. Cocoa's no different as far as that is concerned. However, most other APIs define each of these values as an integer (1, 2, 3, 10, etc.) from 0 to 255, while Cocoa defines it as a floating-point number (0.0, 0.1, 0.5, etc.) from 0 to 1. Cocoa's method is better, because it can allow for (theoretically) an infinite number of colors, including colors that current technology can't even display. However, that comes at a cost; to convert from any other system, you have to add 1 and divide by 256. This doesn't sound like an issue when you're dealing with just one color, and perhaps it isn't, but when you must deal with many thousands (such as with images) things begin to break down. It's times like this that an API which natively understands the integer values comes in handy, and that's where Carbon comes in.

Because just about every big-name developer out there has products for multiple platforms, Carbon is a worthwhile investment for them even if they have no intention of supporting OS9. Carbon isn't just about backward-compatibility, you know.

I don't understand...why do you bring this subject up when we're talking about a rewrite of AppleWorks. For some mysterious reason, you've brought up porting-ease and backwards compatibility into the story...two things that have nothing to do with a complete rewrite of a suite of apps.

I see zero benefits from a pure Carbon rewrite...unless Apple has plans to port this new version to Windows...this wouldn't make sense since it would get MS all riled up and one of the versions (probably the Mac version since Apple seems to keep Mac and Windows versions the same...this may change with the next QuickTime though...who knows) would have to be dumbed down. That would be bad. I want to see Apple use all the fancy new Cocoa APIs.

So tell me again why you brought this subject up when it has nothing to do with the issue at hand?

[Eug Wanker]

Originally posted by Horsepoo!!!:
I see zero benefits from a pure Carbon rewrite...unless Apple has plans to port this new version to Windows...this wouldn't make sense since it would get MS all riled up

AppleWorks 6.2 for Windows

[Krypton]

Originally posted by Millennium:
It still has its uses. In particular, the fact that it is much easier to port code from just about every other API in existence to Carbon than it is to port that same code to Cocoa. This isn't just an Objective-C versus C++ issue either; the design philosophies behind Cocoa are very different from many other operating systems. A basic example can be seen in how colors are defined. Most operating systems define colors based on values for Red, Green, and Blue, and sometimes an alpha channel as well. Cocoa's no different as far as that is concerned. However, most other APIs define each of these values as an integer (1, 2, 3, 10, etc.) from 0 to 255, while Cocoa defines it as a floating-point number (0.0, 0.1, 0.5, etc.) from 0 to 1. Cocoa's method is better, because it can allow for (theoretically) an infinite number of colors, including colors that current technology can't even display. However, that comes at a cost; to convert from any other system, you have to add 1 and divide by 256. This doesn't sound like an issue when you're dealing with just one color, and perhaps it isn't, but when you must deal with many thousands (such as with images) things begin to break down. It's times like this that an API which natively understands the integer values comes in handy, and that's where Carbon comes in.

Because just about every big-name developer out there has products for multiple platforms, Carbon is a worthwhile investment for them even if they have no intention of supporting OS9. Carbon isn't just about backward-compatibility, you know.

Both RealPlayer 10 and SketchUp are great Cocoa apps that retain code compatibility with their Windows versions - not to mention several Cocoa chat clients that use the same libraries as Windows versions (yes I'm aware the libraries aren't written in Cocoa).

[Krypton]

Originally posted by Millennium:
BBEdit, perhaps?

- Toolbars non-customisable
- Liberal use of pixelated OS 9 style interface icons
- Use of old style wait cursors (a big no-no in Apple's eyes)

I agree it was the best answer to my question, but it still doesn't convince me that Carbon is as good. The Finder would be a good choice also, if it didn't crash all the time and lock up when browsing my network.

[Millennium]

Originally posted by Horsepoo!!!:
I don't understand...why do you bring this subject up when we're talking about a rewrite of AppleWorks. For some mysterious reason, you've brought up porting-ease and backwards compatibility into the story...two things that have nothing to do with a complete rewrite of a suite of apps.

Apple still carries a Windows version of AppleWorks. Portability is still an issue.

Besides which, we still have no clue that this is an actual rewrite. It may still be an update. This all assumes, of course, that it even exists. The point is that we don't have any information, aside from a book which hasn't been released and may or may not be badly-titled.

I see zero benefits from a pure Carbon rewrite...unless Apple has plans to port this new version to Windows...this wouldn't make sense since it would get MS all riled up and one of the versions (probably the Mac version since Apple seems to keep Mac and Windows versions the same...this may change with the next QuickTime though...who knows) would have to be dumbed down.[/b]

Why would one version have to be dumbed down?

As for the benefit, Apple is in something of a special case, in that they make the Carbon API. Therefore, they receive one benefit from using it that no other developer could receive: namely, proof that it is a viable API for writing large-scale applications. Would Metrowerks' PowerPlant have been so popular in the OS9 days if Metrowerks had never used it for any of their own apps? Would MFC have gained popularity if Microsoft... wait, Microsoft didn't ever use it for much. Maybe that's why MFC tanked.

[Horsepoo!!!]

Originally posted by Millennium:
Apple still carries a Windows version of AppleWorks. Portability is still an issue.

Besides which, we still have no clue that this is an actual rewrite. It may still be an update. This all assumes, of course, that it even exists. The point is that we don't have any information, aside from a book which hasn't been released and may or may not be badly-titled.

Why would one version have to be dumbed down?

As for the benefit, Apple is in something of a special case, in that they make the Carbon API. Therefore, they receive one benefit from using it that no other developer could receive: namely, proof that it is a viable API for writing large-scale applications. Would Metrowerks' PowerPlant have been so popular in the OS9 days if Metrowerks had never used it for any of their own apps? Would MFC have gained popularity if Microsoft... wait, Microsoft didn't ever use it for much. Maybe that's why MFC tanked.

I dunno but your idea of 'an update done completely in Carbon' is total nonsense since most of the powerful stuff is in Cocoa now. If you actually believe Apple's going to sacrifice not using some of the Cocoa goodies to intermix with Carbon, you're out of your mind and the next 'update' or 'rewrite' would suck very badly.

Apple might want to maintain 'file' compatibility but dumbing down the app because some frameworks don't exist on Windows or making one version better than the other is something I call 'trouble.'

If Apple wants to make AppleWork stop sucking and become a real Office contender, 'an update done completely Carbon' would be the worst thing ever.

[davecom]

You cocoa zealots really don't get it. There's nothing in cocoa that can't be implemented in carbon, and in fact Apple has been adding APIs to both carbon and cocoa to make both 'equal' feature wise. Take it from someone who loves to program with Obj-C/Cocoa, carbon apps are equals.

[Horsepoo!!!]

Originally posted by davecom:
You cocoa zealots really don't get it. There's nothing in cocoa that can't be implemented in carbon, and in fact Apple has been adding APIs to both carbon and cocoa to make both 'equal' feature wise. Take it from someone who loves to program with Obj-C/Cocoa, carbon apps are equals.

This is simply not true. You need to mix both if you want to get the best of both worlds. Cocoa and carbon aren't equal.

In fact, until very soon, to access QuickTime APIs, you had to go through Carbon. But soon, you won't need to.

[davecom]

Originally posted by Horsepoo!!!:
This is simply not true. You need to mix both if you want to get the best of both worlds. Cocoa and carbon aren't equal.

In fact, until very soon, to access QuickTime APIs, you had to go through Carbon. But soon, you won't need to.

I said they were working towards being equal and that it is POSSIBLE to do the same things in both. By the way NSMovie, a cocoa class used Quicktime to play movies since 10.0 so you're wrong about that too. And BTW, Quicktime is just a C API so it can 'natively' be used from just about anything. In fact I directly accessed the Quicktime APIs from a program I wrote a while ago called CCDP. No Carbon involved.