MacOS X finder needs to be re-written in cocoa
The carbon finder works sluggishly and it is not a multithreading program. Each and every time when I have to connect to iDisk or whatever AppleTalk or WinXX environments, the MacOS X Finder just hangs, the cursor spins and you can't do anything, like opening a new finder window, copy/move files. That is annoying, I hope Apple will fix this inconvenience in the next MacOS X update. If so, it would be greater than any new hardware announcement.
BTW, OmniWeb is written by more advanced cocoa environment and it can do much better multithreading than Mozilla whatever the built is until Mozilla is rewritten in cocoa.
BTW, OmniWeb is written by more advanced cocoa environment and it can do much better multithreading than Mozilla whatever the built is until Mozilla is rewritten in cocoa.
Comments
"Carbon SuX0r5!!"
"Cocoa 0wnz j00!!"
<img src="graemlins/oyvey.gif" border="0" alt="[No]" />
[ 03-19-2002: Message edited by: Gambit ]</p>
Besides performance improvements I want some usability improvements, especially for organization and searching. the finder should be kick ass. not something you'd rather not mention in the same sentence with OS X
<strong>Your incorrect in saying it needs to be rewritten in specifically in cocoa. the fact is it needs to be rewritten or completely overhauled. It's seriously flawed in both performance and usability. I'm not exactly sure how it got so bad in performance. and why is it carbon? it's certainly not a carbonized mac os 8.x/9 finder and its not NeXTStep's workspace manager. did they actually write in from scratch in carbon?
</strong><hr></blockquote>
I think at one of the WWDCs, Apple wanted to show developers how viable of a platform Carbon is. However, I don't think the Mac OS X Finder is the best example.
Also, I think there is this issue with resource forks (Cocoa apps stuff up the resource forks of files).
If the finder is currently carbon, then why do it's windows resize live and yet other carbon apps only get the window outline?
Also-side question, why won't carbon apps scroll? Does Apple need to do something, or can that be hacked?
<strong>If the finder is currently carbon, then why do it's windows resize live and yet other carbon apps only get the window outline?</strong><hr></blockquote>Lots of Carbon apps DO use live resizing. It's a simple variable the programmer can switch on or off.
[quote]<strong>Also-side question, why won't carbon apps scroll? Does Apple need to do something, or can that be hacked?</strong><hr></blockquote>WTF? Scroll? Huh? <img src="confused.gif" border="0">
<strong>Curious, and possibly stupid question...
...Also-side question, why won't carbon apps scroll? Does Apple need to do something, or can that be hacked?</strong><hr></blockquote>
Assuming you're referring to using the scroll-wheel on some mice, it's because Cocoa includes built-in drivers for it (and handles the wheel automatically, with no work by the programmer, and Carbon programs must specifically look for scroll wheel movement and react appropriately. And because the programmer must actually do work, many just don't bother.
<strong>...and why is it carbon? it's certainly not a carbonized mac os 8.x/9 finder and its not NeXTStep's workspace manager. did they actually write in from scratch in carbon?</strong><hr></blockquote>
The reason for it being written in Carbon is that there were some things that Cocoa doesn't support the the Finder had to be aware of (such as resource data in the Resource Fork and not the Data Fork).
That just plain sucks.
AirFluf's point is valid that no amount of threading in the upper layers of the system matter if you have a bottleneck below them.
<strong>AirFluf's point is valid that no amount of threading in the upper layers of the system matter if you have a bottleneck below them.</strong><hr></blockquote>
No it's not, 'cause most of the problems caused by the current implementation of the Finder are not due to the iDisk. The problems caused by iDisk slowness would be moot if the Finder was indeed threaded so that it could handle other tasks while waiting for a reply from a WAN. But it can't. So both your posts are narrow-minded (like that better than "stupid"?) because they deal with an isolated problem caused by an obscure combination of events. Making the iDisk respond faster would not remove the fact that if it were to increase its speed to take 2 seconds instead of 20 to read from the disk, the entire Finder would still be locked from user input during that period of time. The same with reading from standard folders. That the Finder takes 30+ seconds to read my MP3-folder (with approx 300+ files & folders) would not annoy me nearly as much if the Finder allowed me to browse other Finder windows while it's idle. But it's completely unresponsive during any task.
And that's not a desired behavior from a supposedly modern and multitasking OS. Or you could just say that it sucks. But then your point would probably pass over a lot of heads who require "adult" language in order to be able to read posts.
<strong>There should be no differences between a well-written cocoa app and a well-written carbon one. Why should we, as users care what language or under what framework an application is written? We shouldn't even be able to tell. I agree that the finder sucks, but that's because it was poorly programmed, not because it was written in carbon. I'll let someone who knows more about the programming side explain why </strong><hr></blockquote>
Ok...I'm fûckin' sick and tired of hearing this 'there should be no differences between a well-written cocoa app and a well-written carbon one'-bullshit. In case you're fückin' blind, you'll realize that cocoa will have features such as drawers that aren't available with the carbon API.
And the truth is...and I know it's hard to swallow...nobody's able to write a good carbon app. That's right mofo! Nobody 'cept maybe Andrew Welch aka moki from Ambrosia and those crazy guys at Panic. All carbon ports lick my nutz. You lick my nutz. And you're stupid if you think carbon is ever gonna produce something worthy of OS X.
Shaddup! All of youz b30tchz! Cocoa is a god send in terms of creating an easy and nice-looking GUI and is a time-saver if you want to implement simple things such as scrollwheel support and services.
There will always be a difference between carbon and cocoa apps...because it's easier to develop a cocoa app and developers are lazy wankers that won't put the effort in making a good carbon app that takes full advantage of OS X since it would require extra code.
Agree or disagree...I don't care. Cocoa 0wnz j00 and it's no joke.
k thx bye.
[Edited to bypass the filters...cuz, hell, to experience the full madness of this post, you gotta see the expletives.]
[ 03-21-2002: Message edited by: kim kap sol ]</p>
<strong> We know what happened to then, don't we?</strong><hr></blockquote>
Ummm..... they made Office:mac v.X?