[samslaves]

We know that the X Finder was developed with PowerPlant from Metrowerks, and that it is a non optimized framework for developing carbon app. But testing OS X (10.0.3) I assume that even QuickTime is Carbonized and non native, so Sherlock. All of these are core technologies; should we expect that Apple brings them all to Cocoa?

QT on X is slow than QT on 9.1.


By
Sam

[honeydew]

Say it with me:
Carbon is a native API. Carbon is a native API. Carbon is a native API.


:o Ok back to your regularly scheduled programming.

[Scrod]

Why do so many people on these forums think that programs written for the Carbon APIs are somehow not native to Mac OS X? If you know ANYTHING about OS X and were capable of logical thought, there's no way you could make this assumption. Before people like you post any more comments like these, you need to actually KNOW something about the way OS X's development environments work. Programs written in Cocoa can access ANY PART OF THE CARBON APIs! Oh, and guess what. QuickTime is a FRAMEWORK. Just because the QuickTime PLAYER is carbonized doesn't mean that QuickTime exists only in the carbon APIs!

QuickTime is tied inextricably to Old School Mac Toolbox code. The APIs needed for QuickTime were even ported to Windows so that QuickTime would work in that environment. Part of the reason Carbon exists is to bring this codebase over to OS X in a modernized format (thus allowing other developers to modernize their apps in a similar fashion).

I don't know how this relates/binds the player to the framework, but there you have it. A rewrite in Cocoa would be a pretty monumental task. Maybe a rewrite of the player?

I wish that Apple would do something about finder and QT. Finder at times is much too slow. The previews especially come to mind here. Currently, my biggest problem with speed is QT. If I want to watch a QT movie, I will wait for classic to start up just so that I can play it using the classic QT player. I have some movies that are encoded at 24 frames a second and will only give me 5 fps playback at normal size in X and the same movie will give me 15 fps doubled inside classic. I can't be the only one that has noticed this! Does anyone any idea why QT is SO SLOW?!?

BTW, I use a Powerbook (Wallstreet) 292Mhz.

[Xestrel]

<wildly unimformed rant>
See - everyone wants people to reprogram stuff in cocoa. But the problem with cocoa is that it's objective-C instead of C++ - so people are sticking with Carbon which is more familiar and in C++. So... how 'bout if apple met people half way and made cocoa an objective-C++ framework? I guess that would mean inventing objective-C++, but whatever... details, people, details.
</wildly unimformed rant>



(man, I just can't spell today...)

[ 06-05-2001: Message edited by: Xestrel ]

[SkullMacPN]

Originally posted by Xestrel:
<STRONG>&lt;wildly unimformed rant&gt;
See - everyone wants people to reprogram stuff in cocoa. But the problem with cocoa is that it's objective-C instead of C++ - so people are sticking with Carbon which is more familiar and in C++. So... how 'bout if apple met people half way and made cocoa an objective-C++ framework? I guess that would mean inventing objective-C++, but whatever... details, people, details.
&lt;/wildly unimformed rant&gt;



(man, I just can't spell today...)

[ 06-05-2001: Message edited by: Xestrel ]</STRONG>

I'm not a programmer, but itsn't Objective C just a superset of C/C++? In other words, its't it just C/C++ with some extra stuff added?

What annoys me about apples own carbon applications is that the mouse scroll wheel does not work. Even third party carbon applications like Thoth can use the mouse scroll wheel. Why can't apple do that with their own carbon apps?

[Developer]

I'm not a programmer, but itsn't Objective C just a superset of C/C++? In other words, its't it just C/C++ with some extra stuff added?

Objective C and C++ are both supersets of C, but they've gone different directions to a certain degree. Objective C is much more dynamic (does a lot at runtime), while C++ tries to do most of the work at compile time (speed was a major concern of the design of the language). That makes it difficult to mix the two, but there has been an Objective C++ compiler at some time.
I think Apple just didn't have the resources to maintain it (they now have Carbon for developers with legacy code).

A Carbon application written with Carbon Events and compiled as Mach-O binary is an as good Mac OS X citizen as a Cocoa app and probably runs faster.


Developer

[Xestrel]

Well - i would think that an advantage to actually maintaining an objective c++ base would enable c++ developers to leverage existing c++ application code which was independent of the system API used.

-xest