MacOS X finder needs to be re-written in cocoa

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

Here we go again...

"Carbon SuX0r5!!"
"Cocoa 0wnz j00!!"

<img src="graemlins/oyvey.gif" border="0" alt="[No]" />

Hark! Hear the ignorant speak! <img src="graemlins/oyvey.gif" border="0" alt="[No]" />

[ 03-19-2002: Message edited by: Gambit ]</p>

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

[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).

I would like to see some builtin search features like in Win2000.

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?

[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">

[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.

[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).

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.

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.

[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.

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.

[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>

[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?

kim kap sol be ridin' the tr00th tr41n!! w00t w0000t!

<img src="graemlins/lol.gif" border="0" alt="[Laughing]" />

Thanks for the serious responses, AirSluf.

[quote]Originally posted by kim kap sol:
<strong>
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.
</strong><hr></blockquote>

And the reverse is true. There are a number of Carbon features that Cocoa cannot access. So the two APIs are roughly even.

[quote]Originally posted by kim kap sol:
<strong>
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.
</strong><hr></blockquote>

Ahem, *I* write a good Carbon app.
<a href="http://homepage.mac.com/mbenonis/cranberry/" target="_blank">http://homepage.mac.com/mbenonis/cranberry/</a>

[quote]Originally posted by kim kap sol:
<strong>
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.
</strong><hr></blockquote>

But you *can* do all of these things in Carbon. They may require extra work, but it will achieve the same goal in the end.

[quote]Originally posted by kim kap sol:
<strong>
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.
</strong><hr></blockquote>

*I* am not a "lazy wanker." I have spent hours trying to make my *Carbon* app (see above) look and behave just like a Cocoa app. Heck, I've even spent money on it! And I'm giving away my app!

[quote]Originally posted by kim kap sol:
<strong>
Agree or disagree...I don't care. Cocoa 0wnz j00 and it's no joke.
</strong><hr></blockquote>

And you would be wrong.

PS-If you want anyone to take you seriously, you need to learn how to write in proper english. Some of us find it-gasp!-easier to read a post written properly, And some of us-gasp!-take a well written post more seriously than one written in god-knows-what.

[quote]Originally posted by graphiteman:
<strong>
And the reverse is true. There are a number of Carbon features that Cocoa cannot access. So the two APIs are roughly even.
</strong>
<hr></blockquote>

Oh reaaaally? Like which ones genius boy!? Back up you claims, or nobody will be able to *you* seriously even if you programmed Cranberry, a decent app (albeit with shitty non-Aqua toolbar icons).

[quote]
<strong>
But you *can* do all of these things in Carbon. They may require extra work, but it will achieve the same goal in the end.
</strong>
<hr></blockquote>

Yes, yes, yes...selective quoting will get you nowhere. I mentioned that all of this can be done but with 'extra work'...and most developers aren't ready to put this extra work in. Except a handful of developers...including you.

I'm sad and hurt that you felt like the target of my rantings. Haven't you heard that there's 'exceptions to [most] rules?' You, Andrew Welch and the boys at Panic are this exception.

[quote]
<strong>
*I* am not a "lazy wanker." I have spent hours trying to make my *Carbon* app (see above) look and behave just like a Cocoa app. Heck, I've even spent money on it! And I'm giving away my app!
</strong>
<hr></blockquote>

Good for you...I hope there are more good carbon developers like you out there. So far there aren't many. You're a respectable developer...but alas, you can't say your app behaves like a cocoa app. You'd be wrong.

[quote]
<strong>
And you would be wrong.

PS-If you want anyone to take you seriously, you need to learn how to write in proper english. Some of us find it-gasp!-easier to read a post written properly, And some of us-gasp!-take a well written post more seriously than one written in god-knows-what.</strong><hr></blockquote>

Nah, I wouldn't be wrong...99.9% of the developers won't put the required effort into a carbon app to make them on par with cocoa apps. Therefore carbon sucks.

Obviously you did take my poorly written post seriously if you took the time to dissect it bit by bit. Thank you for proving yourself wrong.

That is all...buhbye now.

[quote]Originally posted by kim kap sol:
<strong>
Oh reaaaally? Like which ones genius boy!? Back up you claims, or nobody will be able to *you* seriously even if you programmed Cranberry, a decent app (albeit with shitty non-Aqua toolbar icons).
</strong><hr></blockquote>

Whoa, I take my comment back...I actually downloaded your app and tried it out.

1st mistake...REALBasic. LOL!

Here's a list of things missing in your app that I've discovered in the first 30 seconds of testing:
No scrollwheel support.
A half-assed sheet implementation (sometimes save invokes a sheet...sometimes it doesn't.)
No customizable toolbar (or is that a cocoa-only feature...the Finder has it but is it a hack?)
No services support.

Here's a list of missing features that aren't your fault because they're cocoa-only features:
Drawers.

And here are non carbon-vs-cocoa-related issues:

Here's a bug I saw in the first 5 seconds of scrolling some Marathon scripts:
Text occasionally scrolls out of the text field. Screenshot to come.

Things I'm not too impressed with:
Your sucktacular application icon and the toolbar icons.

Sorry, bub, your app doesn't pass the test...and I haven't even tested it fully. I'd probably find a lot more problems and carbonish pet peeves if I took any more time.

[ 03-24-2002: Message edited by: kim kap sol ]</p>

[quote]Originally posted by kim kap sol:
<strong>

Whoa, I take my comment back...I actually downloaded your app and tried it out.

1st mistake...REALBasic. LOL!
</strong><hr></blockquote>

And would you please explain why REALbasic is a mistake?

[quote]Originally posted by kim kap sol:
<strong>
Here's a list of things missing in your app that I've discovered in the first 30 seconds of testing:
No scrollwheel support.
</strong><hr></blockquote>

I don't have a scrollwheel mouse. So I haven't had a chance to implement it. And plase remember that the application is in BETA testing: some things may not be there or work as expected.

[quote]Originally posted by kim kap sol:
<strong>
A half-assed sheet implementation (sometimes save invokes a sheet...sometimes it doesn't.)
</strong><hr></blockquote>

Could you explain further?

[quote]Originally posted by kim kap sol:
<strong>
No customizable toolbar (or is that a cocoa-only feature...the Finder has it but is it a hack?)
</strong><hr></blockquote>

It is a hack in the finder, and in my app, there is no need for customization (what you see is what you get).

[quote]Originally posted by kim kap sol:
<strong>
No services support.
</strong><hr></blockquote>

See above - It's a BETA!

[quote]Originally posted by kim kap sol:
<strong>
Here's a list of missing features that aren't your fault because they're cocoa-only features:
Drawers.
</strong><hr></blockquote>

A short list that is irrelevant because I have no need for drawers. And many people dislike them, myself included.

[quote]Originally posted by kim kap sol:
<strong>
And here are non carbon-vs-cocoa-related issues:

Here's a bug I saw in the first 5 seconds of scrolling some Marathon scripts:
Text occasionally scrolls out of the text field. Screenshot to come.
</strong><hr></blockquote>

Don't bother. Its a known bug.

[quote]Originally posted by kim kap sol:
<strong>
Things I'm not too impressed with:
Your sucktacular application icon and the toolbar icons.
</strong><hr></blockquote>

That would be an OPINION, and therefore carries no weight.

[quote]Originally posted by kim kap sol:
<strong>
Sorry, bub, your app doesn't pass the test...and I haven't even tested it fully. I'd probably find a lot more problems and carbonish pet peeves if I took any more time.
</strong><hr></blockquote>

So, are you saying that every Cocoa app is perfect because it is Cocoa, and that Carbon is bad because it is Carbon? I'd bet that I could find a bunch of problems with Cocoa apps to criticize.

[edit: spelling]

[ 03-24-2002: Message edited by: graphiteman ]</p>

[quote]Originally posted by graphiteman:
<strong>
I don't have a scrollwheel mouse. So I haven't had a chance to implement it. And plase remember that the application is in BETA testing: some things may not be there or work as expected.
</strong><hr></blockquote>

Typical answer...

[quote]
<strong>
Could you explain further?
</strong><hr></blockquote>

Quitting the app through the menu or through cmd-q will make the save sheet drop down if you have some unsaved changes. Using 'Save' or 'Save As' from the menu will not make a save sheet drop but instead make the save dialog box pop up.

[quote]
<strong>
It is a hack in the finder, and in my app, there is no need for customization (what you see is what you get).
</strong><hr></blockquote>

Another typical answer to defend carbon..."I don't need to customize my toolbar, so you don't either."

So here we have the first reason why carbon is crap...uncustomizable toolbar. While I don't much care if a toolbar is customizable or not...I do care about consistency. Carbon and cocoa apps do not feel or act the same way (they might to the untrained eye I guess).

[quote]
<strong>
See above - It's a BETA!
</strong><hr></blockquote>

Yes, yes, yes, I see what you're doing here. Because it's beta you're exempted from any of the comments I make about your application.

Don't announce your program as a model carbon app if it's not...I don't care if it's beta or not.

[quote]
<strong>
A short list that is irrelevant because I have no need for drawers. And many people dislike them, myself included.
</strong><hr></blockquote>

I agree, this one is a gray area...if not implemented properly, drawers can be a pain more than anything else. Although I can think of some ideas of what you could have done with drawers if your app was cocoa. If you want my ideas, say so...I'll send you an email and some GUI mockups (although I bet you don't want my ideas now that I've ridiculed your app. It's up to you if you want feedback and ideas.)

[quote]
<strong>
That would be an OPINION, and therefore carries no weight.
</strong><hr></blockquote>

You're right...it's an opinion and it carries no weight. But I do enjoy consistency with the Aqua GUI and icons that don't follow the guidelines stick out like a sore thumb.

[quote]
<strong>
So, are you saying that every Cocoa app is perfect because it is Cocoa, and that Carbon is bad because it is Carbon? I'd bet that I could find a bunch of problems with Cocoa apps to criticize.
</strong><hr></blockquote>

Nope...not saying that at all. Just saying that cocoa is better for the developer and the end-user.

Better for the developer since you inherit behaviors/features for free such as a scrollwheel support, services, customizable toolbars, sheets etc...

Better for the end-user because consistency is where it's at. Having scrollwheel support in on app and lack of scrollwheel support in another is no good. Having customizable toolbars in one app and lack of customizable toolbars in another is no good. Having services in one app...well you get the picture right?

You say that you haven't put in scrollwheel support because you don't have a scrollwheel mouse. Fine. But if you were programming in cocoa, you wouldn't need a scrollwheel mouse to test out scrollwheel support because the scrollwheel support would be there already.

Anyways...my advice to you is: Don't announce your program as a model carbon app if it isn't. I understand it's still in beta but you have to realize that you asked for it by telling me that your app is a great carbon app that couldn't be differentiated from a cocoa app.

[ 03-24-2002: Message edited by: kim kap sol ]</p>

kim kap sol,

please post here more <img src="graemlins/lol.gif" border="0" alt="[Laughing]" />

[quote]Originally posted by applenut:
<strong>kim kap sol,

please post here more <img src="graemlins/lol.gif" border="0" alt="[Laughing]" /> </strong><hr></blockquote>

Why?

[quote]Originally posted by kim kap sol:
<strong>
Anyways...my advice to you is: Don't announce your program as a model carbon app if it isn't. I understand it's still in beta but you have to realize that you asked for it by telling me that your app is a great carbon app that couldn't be differentiated from a cocoa app.</strong><hr></blockquote>

OK, well let's end this discussion (It was fun, wasn't it?). I would like to hear your suggestions; it will make Cranberry a better Mac OS X citizen.

A few notes:
The way that I am implementing toolbars is with a 3rd party module that actually draws everything like a Cocoa app does. It does not access the NSToolbar class (It's not accessable to Carbon apps, IIRC). The customize sheet would be extremely difficult to do as the sheet must come out of the toolbar and not the title bar, and I don't believe that to be possible in Carbon.

I thought REALbasic had Scrollwheel support, I'll double check that. And if it doesn't, I know of another way to do that. To be honest, you are the first person to even make me think about it.

Save sheets shouldn't be too hard to do.

I apprecate your poiting these things out, as I want my app to be a first class citizen in Mac OS X.

PS-I would still like to hear how RB is a mistake

[quote]Originally posted by graphiteman:
<strong>PS-I would still like to hear how RB is a mistake </strong><hr></blockquote>Most people have a hatred for RB apps because most of them are crap. Just look at the comments for some of the uglier RB apps on VersionTracker! Whoo-boy! RB has a history of major, annoying GUI bugs with OSX including the rainbow-colored text (which I think was fixed) and the mis-aligned background "pinstripes" behind widgets like checkboxes, text fields, and the like. Plus, many RB apps seem extraordinarily l-a-r-g-e and s-l-o-w.

Of course, that doesn't mean *all* RealBasic apps are inherently bad. Though, there have been SO MANY bad apps, it's hard to shake the reputation.

[quote]Originally posted by starfleetX:
<strong>Most people have a hatred for RB apps because most of them are crap. Just look at the comments for some of the uglier RB apps on VersionTracker! Whoo-boy! RB has a history of major, annoying GUI bugs with OSX including the rainbow-colored text (which I think was fixed) and the mis-aligned background "pinstripes" behind widgets like checkboxes, text fields, and the like. Plus, many RB apps seem extraordinarily l-a-r-g-e and s-l-o-w.

Of course, that doesn't mean *all* RealBasic apps are inherently bad. Though, there have been SO MANY bad apps, it's hard to shake the reputation.</strong><hr></blockquote>

The Rainbow colored text issue was fixed 6 months ago, and the misaligned pin stripes issue has been fixed in the 4.5 alphas. The reason that took so long is that it required a complete rewrite of how the interface was handled to support a parent-child relationship between, say, a button and a tab panel.

As far as the slowness issue, REAL Software is writing a new compiler (which is now available in the form of RBScript) that will be included into REALbasic as the main compiler in the near future (probably 5.0).

I just wanted to clear up these myths.

graphiteman,

I just saw this on VersionTracker. This might hopefully help you implement the new carbon events without much pain.

<a href="http://www.versiontracker.com/moreinfo.fcgi?id=12933&db=macosx" target="_blank">Carbon Events RB Plugin</a>

Actually, I already use it. But thanks for the suggestion.

AirSluf:

I don't think the Finder problem is related to any kernel mutexes.

- Unix file systems store each directory in a regular file, containing the names of the files in that directory and their inodes. If you want to read file specific information, you have to iterate over all these files (inodes). The OSX Finder provides such information (modification date, size etc.), thus a lot of inodes have to be read if you do a directory listing. However, this is of course not done with only one low-level system call but with at least one for each file (I don't know OSX's vfs, but it will ultimately come down to some sort of lookup/get call). So, if you have to go through a lot of files, you can easily stop at every point and switch to another thread, leaving the Finder fully responsive.

- Even if you're right with your funnel theory, connecting to an iDisk should not block local disk operations or even general event handling in the Finder since I don't think that reading a local directory or selecting a folder does actually perform network system calls, do you?

- I also don't think that connecting to an iDisk is only one BLOCKING sys call, and iDisk navigation even less. Therefore you should be able to connect and navigate several iDisks in parallel without having to wait for each operation to fully complete. (Webdav uses tcp, which means that all connect/send/receive operations can be done asynchronously.)

Conclusion: The Finder does use multiple threads for file copying etc. but doesn't do so for event handling and navigation(dir-listing). I call this a very bad design. IMHO, locks may indeed be the problem if you want to do several dn lookups at the same time or somethink similar, but not if you want to work with a big/remote directory and always have a completely unresponsive Finder.

123

[ 03-27-2002: Message edited by: 123 ]</p>

[quote]Originally posted by starfleetX:
<strong>Most people have a hatred for RB apps because most of them are crap. </strong><hr></blockquote>Monica is great; although it'd be greater if it re-connected when a download is interrupted as well as the OS 9 version did (I have a feeling it's Apple's fault, though)

Note:
I clearly said that I don't think all RealBasic programs are bad. I use several StimpSoft (RIP) apps regularly and they're all written in RB. I simply wanted to state the simple truth that RB has a bad reputation because of the shabby apps out there that were written by amateur programmers. At least 2/3 of the RB apps I download go straight to the trash because they're just ugly, disorganized, and slow. This isn't entirely RB's fault but much of the programmers.

Play it cool, guys. :cool:

[ 03-27-2002: Message edited by: starfleetX ]</p>

[quote]Originally posted by graphiteman:
<strong>

As far as the slowness issue, REAL Software is writing a new compiler (which is now available in the form of RBScript) that will be included into REALbasic as the main compiler in the near future (probably 5.0).
</strong><hr></blockquote>


They also said that this would be incorporated into version 4.x, but as we all know, it wasn't.