MacOS X finder needs to be re-written in cocoa

Posted:
in macOS edited January 2014
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.
«1345

Comments

  • Reply 1 of 89
    torifiletorifile Posts: 4,024member
    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
  • Reply 2 of 89
    Here we go again...



    "Carbon SuX0r5!!"

    "Cocoa 0wnz j00!!"



    <img src="graemlins/oyvey.gif" border="0" alt="[No]" />
  • Reply 3 of 89
    gambitgambit Posts: 475member
    Hark! Hear the ignorant speak! <img src="graemlins/oyvey.gif" border="0" alt="[No]" />



    [ 03-19-2002: Message edited by: Gambit ]</p>
  • Reply 4 of 89
    applenutapplenut Posts: 5,768member
    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?



    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
  • Reply 5 of 89
    undotwaundotwa Posts: 97member
    [quote]Originally posted by applenut:

    <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).
  • Reply 6 of 89
    outsideroutsider Posts: 6,008member
    I would like to see some builtin search features like in Win2000.
  • Reply 7 of 89
    kidredkidred Posts: 2,402member
    Curious, and possibly stupid question.



    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?
  • Reply 8 of 89
    [quote]Originally posted by KidRed:

    <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">
  • Reply 9 of 89
    [quote]Originally posted by KidRed:

    <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.
  • Reply 10 of 89
    [quote]Originally posted by applenut:

    <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).
  • Reply 11 of 89
    airslufairsluf Posts: 1,861member
  • Reply 12 of 89
    airsluf&gt; Your whole post is stupid due to the simple fact that the problem with the Finder is that it isn't multithreaded at all, networking or no networking. When I try to open up my mp3 directory in the Finder (which I never do anymore, just simply drop new files and folders on it) and it uses 30 seconds to scan the directory and show me its contents, the whole Finder is locked. This has nothing to do with networking, this has to do with the fact that the Finder takes too long to do simple things, and when it does take too long the entire application gets jammed and you can't do anything else to your file system.



    That just plain sucks.
  • Reply 13 of 89
    buonrottobuonrotto Posts: 6,368member
    Childish post there, "stupid," "sucks," don't we have better things to say and better ways to say them? At least AirFluf taught us something and had solid thinking. Yes, the Finder needs serious multithreading, bug fixes, and features added. None of this requires Cocoa, and while Cocoa makes this stuff easier to do, at this point, it would likely be more work to "reinvent the wheel" than to alter the existing code.



    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.
  • Reply 14 of 89
    [quote]Originally posted by BuonRotto:

    <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.
  • Reply 15 of 89
    buonrottobuonrotto Posts: 6,368member
    My understanding of what AirFluf said is that there are only two main threads in the kernel - the BSD thread, and the "everything else" thread. So as I understood it, iDisk and almost everything else is being funnelled into that "everything else" thread. I could be wrong, this isn't exactly what I do for a living.
  • Reply 16 of 89
    airslufairsluf Posts: 1,861member
  • Reply 17 of 89
    kim kap solkim kap sol Posts: 2,987member
    [quote]Originally posted by torifile:

    <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>
  • Reply 18 of 89
    airslufairsluf Posts: 1,861member
  • Reply 19 of 89
    gambitgambit Posts: 475member
    [quote]Originally posted by AirSluf:

    <strong> We know what happened to then, don't we?</strong><hr></blockquote>



    Ummm..... they made Office:mac v.X?
  • Reply 20 of 89
    airslufairsluf Posts: 1,861member
Sign In or Register to comment.