Mac os 10.2

Actually, Cocoa/Carbon are fairly equal in performance. It is just easier to write better code using Cocoa than it is Carbon since Cocoa enforces its framework on the programmer. You can technically use either and get the same result. For your purposes though, Cocoa will be a bit better, since it has a more polished interface into Quartz, and probably IOKit (the direct hardware interface)

However, there is one thing I noticed Carbon does properly that Cocoa needs work on. Cocoa apps do not see the theme data for the title bar text. So whenever I use a black theme, I can't see the title text in OmniWeb/etc, while Carbon apps recognize and use the theme data.

Bad Apple! Be consistent!

Maybe this will change in 10.2, maybe it won't. Time will tell. (See! I made it SOMEWHAT on-topic!)
 
Vic,
Check out SVG. It's cross platform. Adobe pushes it but it isn't proprietary like flash, and i think it works with java (not sure.) But I think it's definitely worth checking out.
 
Originally posted by dlookus
Vic,
Check out SVG. It's cross platform. Adobe pushes it but it isn't proprietary like flash, and i think it works with java (not sure.) But I think it's definitely worth checking out.
Click to expand...


k i will, i once had a whole bunch of usefull bookmarks about it, i think it's really nice that the w3c is coming up with a sandard for vector graphics that could be as powerfull as flash. speacking about standards, when will the .doc format b made opensource standard? :) i think this is one of the best remedias the gov could push on MS to opensource internet explorer and slice up the doc format... adobe at least opened up their pdf format for inspection by anyone.
 
If there is going to be an open word processing format it should be done in XML like the new StarOffice/OpenOffice one.
 
thqt's not what i mean, the .doc format is EVERYWHERE, so you have to make every word aplication compatible with that or people won't even consider it. that is why i suggestd making .doc opensource
 
Originally posted by kilowatt


I agree with 99.999% of what simx said. But, the finder is not a carbon/cocoa hybrid. I think I started that rumor, so I'll stop it too. I talked with some developers at apple, they said the finder was created in CW in os9.

The parts that look like cocoa were hard coded with snips from the Cocoa API. There's not a scratch of cocoa code in the osx finder though. Its all hard coded. Each tool bar, each sheet, and each drawer. All coded by hand, on a per-object basis.

Just watch the threads the finder creates. 3 I think, and one per contexual menu.
Click to expand...

Yeah, it was you who got me thinking. It does make sense if you look at it, though, to think that the Finder is a Carbon/Cocoa hybrid.

BAD kilo for spreading rumors about the OS X Finder! ;)
 
hehe sorry bout that simx :)

In response to Krevinek's comments on cocoa and carbon:

I've dabbled in both areas, and now I only program cocoa. There are *HUGE* differences between carbon and cocoa.

Let me start with the obvious:
Cocoa is multithreaded by its nature. On a unix system with two or more processors, this makes a huge difference in speed. Even on single processors, the mach kernel is optomized for multithreaded applications. Thats what a microkernel is usually for.

Also, programming wise, cocoa is far more object oriented than carbon. With cocoa, you can send messages to almost anything. And, its polymorphic, meaning each class cab implement its own version of a method.

The advantages of cocoa over carbon are simply staggering. I don't know about this 'theme' stuff, but from what I can tell, on older, slower, systems running osx (like beige g3's), cocoa apps run alot faster. On my g4, its not as noticeable. But on slower systems it really is.

If you want to see the finder's thread count first-hand, open up Thread View.app located in /Developer/Applications . Press apple-n, and select the finder. Open a few windows in the finder.

In almost any self-respecting cocoa application, you would see new threads for each window opened.

However, all I see is three threads, one of them accounting for 99% of the work.

My point is that the finder isn't cocoa, and that cocoa is better.

Vic, I think apple is going to work mostly on improving the carbon finder for now. but, perhaps after 10.5, we'll start seeing beta cocoa finders. I hope so anyway :)
 
well said kilo, you need to post more ;). A cocoa finder would be really really nice! Why is the finder carbon anyways? Wasn't it based off the NeXTstep file finder or whatever it was called. And that app was cocoa? Or did apple make a new app?
 
Originally posted by simX


3. Anim8r: OS X on Intel will only be in your dreams. While Apple may be secretly developing an OS X build that goes on Intel alongside the Mac version, rest assured that that line of builds will only be released when Motorola goes up in smoke. And by that time, Apple or IBM will have bought the PPC assets, in which case we'd have to wait 'til IBM or Apple itself go up in smoke.

In short, it's not gonna happen. So stop dreaming about it.
Click to expand...

Well Sim... I aint dreaming.
Since I am getting this info from within Intel and Apple i think it is probably pretty reliable. My two sources don't know each other and I may have blown a couple of friendships releasing this info. But i think it is close enough to general release that it might be OK.
Bear in mind that this is not going to result in an OEM version of OSX or even a boxed Intel version that can be installed on just any PC. This is just giving Apple another source for procs and also lets them squash the "PPC is just too slow" arguments that are the last bastion of PC holdouts.
 
I would like to point out to you (kilowatt) that I was stating Carbon vs Cocoa from a performance standpoint, rather than a programmer's preference standpoint. I also pointed out that it was EASIER to write better code in Cocoa than Carbon, but Carbon can be every bit as fast as Cocoa. Neither Cocoa or Carbon will not multithread for you AFAIK. To do so would needlessly add overhead for apps that simply don't need the benefits of multiple threads. True, many major apps need multiple threads, but there are smaller, simpler single-task apps that don't. The best judge on when to multithread should be the programmer, not Apple.

Your points are fairly well made, but I was arguing a different point, and was never disagreeing with yours in the first place (I like the Cocoa API as a programmer myself, I am personally used to C++ myself, and would like to see Objective-C++ or something of the like to make me more comfortable).

BTW, it isn't uncommon for a single thread to be doing a lot of the work in non-OO multithreaded apps. Usually the secondary threads are used to manage the back-end of the application, and you will notice this effect even under some OO multithreaded apps where you have one back-end engine for a network or device that only does work when the device/network says there is something to do. Even under Omniweb it is fairly common for a single window thread to be doing most of the work the app is doing, since users tend not to load down a request in EVERY window and then wait for them all to complete.
 
Krevinek,
looks like I mistook your coments about cocoa. I think we're saying the same thing, just differently.

Cocoa is a fine language, and personally, I prefer working in cocoa apps to carbon ones. On a user and programmer basis.

My statements about threading were probably over-contrasting. Either language can certainly be multithreaded. But the cocoa language is just naturally like this, seems to take a little more work with carbon.

Its also true that many cocoa functions are just calls to carbon. I don't quite understand why, but thats what the cocoa API says.

However, quite frequently we see cocoa functionality becoming part of the carbon structure. Take the 'services' menu (accessed by pulling down the 'application menu' and selecting 'Services'). The Services menu in Mac OS X 10.0 was only available to cocoa applications. However, now you will see it available in almost any application. (correct me if I'm wrong, I do see this could be merely some modifications to the services widget).

BTW Krevinek, you say you're an evil power surge user. Powersurge, if I'm not mistaken, is the computer between the 9600 and the Beige G3 that had a G4 processor in it (like the beige g3) but the 'power' features of the 8500-9600 (such as all those PCI and ram slots :) ). As far as I know, this computer was never sold to the public...

you gotta tell us how you got it! :D
 
PowerSurge actually refers to the motherboard design codename used in the 7xxx, 8xxx, and 9xxx models that contained 603 or 604 chips. Although I did get to toy with one of the Altivec-enhanced G3/4 prototypes as part of my job awhile back. It was a beige G3 minitower with the daughtercard replaced with the prototype chip. Still works fairly nicely too. We were spiffing it back up for use by the owner or a close friend/relation to the owner.

Although keeping not-quite-on-topic, Cocoa/Carbon are starting to move towards parity, and Apple made that quite clear through some of the Carbon developments like CoreFoundation (which gives Carbon CFString/etc which match up with NSString and so on). Cocoa is not multithreaded without the programmer explicitly describing a thread task. It sure as hell is easier to make a thread in Cocoa and Java than in Carbon, but so is using the BSD pthreads available under OS X. ;)
 
You must log in or register to reply here.
Back
Top