MacOS X finder needs to be re-written in cocoa - Page 2

I'm not sure what version RealBasic is up to, or what version I last bought was either, but I do know that I don't like the fact that they upgrade all the time, and charge you an arm, and a leg for it. I've paid those dicks probably $700 I could have bought codewarrior for that, and been much happier. Plus + It's for shit anyway. S-L-O-W-! I think it's a dead end programming compared to all the latest options there are for the Mac platform now that OS 10 is comming of age.

-------THE FINDER------

As has been previously stated:
The Finder is not a Cabon Port of a legacy finder to OS 10.

I've opened mine up a few times with different tools, and I think if you open it using resorcerer for X it says "Fake Finder" right there.
I think of it as what pins the dock down in place at it's starting point, and all apps float in to the dock from there. Apple could have called it anything. I think they used the finder to make you more comfortable. Sometimes I thnk it lags because some of the XML utilization in the dock could be optimized better, but I'm not sure realy because I'm not all that familiar with XML yet so I'm essentaily talkin' out of my ass.

[quote]Originally posted by onlooker:
<strong>I've opened mine up a few times with different tools, and I think if you open it using resorcerer for X it says "Fake Finder" right there.</strong><hr></blockquote>You opened the wrong thing.

Mac OS X's Finder is actually a folder called Finder.app. The "fake" Finder you found is actually just a dummy file to let older systems (OS 9) recognize the /System folder as a valid bootable system.

[quote]Originally posted by AirSluf:
<strong>
As for the last, the whole Finder does not grind to a halt when working on remote directories. Just the single Finder window that is accessing the remote directory--iDisk here. All other Finder windows work fine as long as you do not try to also access the (same) iDisk in them as well.</strong><hr></blockquote>

Yes, now wouldn't that be a total pain? This is how the Finder should work when working with regular directories also. Say it's run into a folder containing a lot of files/inodes/whatever (have you noticed I'm not that into techspeak? =) that it has to read, then just show the spinning arrows in the top right corner of the statusbar while loading and let you continue working with other Finder-windows. This should be possible, since other applications can access the file system just fine while the Finder's locked in the Spinning Harddisk-cursor Of Perpetual Annyoance. While the Finder's busy spending a minute rolling its thumbs trying to read my 300+ file & folder directory, I can easily switch to BBEdit and use the file dialogue to browse, open and save files.

So why shouldn't the Finder be able to do this? This makes me think there's something more fundamentally wrong with the way the Finder's coded rather than blaming it on the kernel.

[ 03-28-2002: Message edited by: Whyatt Thrash ]</p>

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

I'm guessing that the reason for iDisk access blocking the Finder is just that it's a half-arsed implementation, as it has been since Mac OS 9. It seems that they simply plugged in some remote directory functionality under the normal calls for folder navigation, so the Finder does all those things like reloading a folder's contents when the window is activated, checking if the folder still exists when you try to drop a file on it, and getting a file's information and preview when you select it, just as if it was a local disk. Those calls are probably implemented as simple function calls, which return very quickly for local file listings, but when they have to get all that information through a modem, the spinning cursor is what you get.
So (if any of my speculation is actually true), they should do two things:
- Rethink the way they wait for those meant-to-be-quick functions to finish, like through callbacks or more threads.
- Make the Finder more aware of remote disks, so it only accesses them when it really has to and uses more or smarter caching.

[quote]Originally posted by starfleetX:
<strong>You opened the wrong thing.

Mac OS X's Finder is actually a folder called Finder.app. The "fake" Finder you found is actually just a dummy file to let older systems (OS 9) recognize the /System folder as a valid bootable system.</strong><hr></blockquote>

Your right. Duh.. I was starting to think I removed that line (fake finder) from the finder.app all together for some reason.

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

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.

</strong><hr></blockquote>

:confused:

This fails any sort of test of elemental logic. I was enjoying the posts until you decided that carbon sucks because developers are lazy, (which appears to be a constant point with you.)

Carbon might suck for other reasons, but it's hardly Carbon's fault that the developer community is a burr in your ass.

AirSluf: (what does that MEAN, anyway?) Won't putting more 'funnels' into the kernal make the kernal more open to crashes? The less you have accessing the kernal the more stable the kernal theoretically is. Right?

[quote]Originally posted by Gambit:
<strong>AirSluf: (what does that MEAN, anyway?) Won't putting more 'funnels' into the kernal make the kernal more open to crashes? The less you have accessing the kernal the more stable the kernal theoretically is. Right?</strong><hr></blockquote>

Kernel. Kernel. Kernel kernel kernel. Now you try.

-DisgruntledQS733Owner

Amar:

Exactly! A level of abstraction (as provided by a virtual file system) is very useful, though. Instead of having to rewrite code for all kinds of file systems, a programmer can just use generic calls for all file systems (remote nfs, local ufs etc.). You don't even have to know what file system you are accessing. However, these calls should of course not block or you need at least to be aware that they do and that there is a huge difference between blocking local and blocking network access (which can take an indefinite time to complete). Unfortunately, the Finder developers don't seem to understand that.


AirSluf:

As I've already stated, a directory listing is not just one sys call. This means that you are in kernel mode only for very short time periods. Now, how do you want to hold the kernel funnel while being in user space? You can't. Hence, it's perfectly possible to implement file browsers who work in parallel even on the very same directory.

I also don't see how this should lead to an inconsistent file system. System calls which change file or inode information are "atomic" in the sense that inodes are being locked during those operations (on a per inode basis). Please show me an example of how you get an inconsistent file system (I am talking about the file system itself, not the Finder representation thereof).


Now, please perform these two experiments (I haven't updated to 10.1.3 yet, so these problems may already be resolved):

Chose "connect to server" and try to connect to "http://www.apple.com".
A nice dialog appears. Now, while the finder is trying to connect, go to your home directory and create a new folder. Oops... that's what I call a carefully designed threading concept!!!

Cancel the connection. Open two Finder windows and move them next to each other. Now connect to an actually existing iDisk. While the Finder is connecting, keep switching between the two Finder windows. At some point, the spinning CD will appear, you can't switch between the two windows during that time although these windows have absolutely NOTHING to do with BSD network services.

Accessing vnodes could actually be implemented in two ways (As I've said, I don't know much about the implementation in darwin):

- blocking: you make a sys call and will be put to sleep until the node can be loaded and becomes available. In this case you would lose the funnel and all other threads could compete for it, too.

-non-blocking: A call would immediately return and you would have to poll or something.

Either way, you wouldn't hold the funnel long enough for other threads not being able to do event checking, which is the reason for the appearance of the spinning disk cursor . BTW: This is also why always the whole app is blocked (not just one window as you've stated). The simple explanation for this behaviour (network as well as dir listing) is that the Finder is poorly programmed.

123

AirSluf,

I agree that there are several ways to deal with the Finder problems and I also want those issues to be resolved sooner than later. However, the only point I am intending to make here is that the kernel funnels are not responsible for most of the Finder's sluggishness/unresponsive CD spinning, especially not when reading a directory. It's obvious that a user app like the Finder has to deal with inconsistency and probably has to develop its own locking/notifying/whatever mechanisms, but that's the Finder's own problem and not a kernel issue (and it's not done well at the moment).

[quote]
1. Did you really mean to cause that panic!
<hr></blockquote>

No, I only wanted to show you that modal dialog. As you've said, this IS a design issue. Who would ever use a modal dialog here? This is just to demonstrate the Finder developers' lack of understanding of thread design/organizing, which I still make responsible for most of the Finder's blocking issues.


[quote]
1/2 sec, just enough to notice + a smidge. Not enough to get me upset though.
<hr></blockquote>

Actual times don't matter, design matters. For you it's still fast enough, for others it's not. Besides, all sort of things may happen and this 1/2 second becomes a minute. See, as long as you can't guarantee upper limits for delays caused by system calls you can't control, blocking JUST MUST NOT happen, never! You can't just say, well, reading a directory usually takes less than half a second, so let's not set up a seperate thread for event checking during that time. Someone has a few thousand files in a directory on a slow device or uses a remote device with a ping of several seconds and the delay becomes unbearable.

You write, on a DP, only the target window doesn't respond but the others work fine (now that's interesting, have to check this on a DP)... well, this is exactly (more or less, you should also be able to move that window around or close it, for example) how it should work on SP machines, too. Unfortunately, it doesn't.

123

Well said 123, you managed to say what I was trying to convey in a manner understandable (and thereby unarguable) to the techies. Kudos matey! ^_^

You just continue believing in yourself...

[ 04-03-2002: Message edited by: Whyatt Thrash ]</p>

I can't speculate on what the problems with the Finder are on a system-level basis. What I can tell you and have been telling all along is that your theory on the implementation of funnels are damn wrong, and that's what you've been adamantly suggesting throughout this entire thread.

All I'm suggesting are two points. First you should of course try to determine the source of the problem and fix that. But funnels are not the issue, and adding more wouldn't resolve the issue, because while the Finder remains locked (maybe because was programmed to think that there should be a funnel lock and prevent further input) ANY OTHER app can STILL access the file system through BSD system calls just fine. Read directories, open/save files whatever. The Finder is the only app that remains locked. So the "poor implementation" of funnels is NOT IT.

Of course Finder programmers should try to find why it's so slow and solve that problem, but something I find much more disturbing than the fact that things are slow (which the whole OS is more or less) is the fact that the Finder's programmed in such a manner as to prevent user input while a task is being performed, no matter what the task is. Reading a file directory in one window shouldn't prevent other Finder windows from reading/copying files, whatever. Of course that's a design decision, but not one that coincides with the marketing of OS X as a multitasking OS.

Now before you start blurting out techspeak, try to understand the problem on a user-level basis. Because when it comes down to it, that's all that matters. 123 has understood the problem at hand, and I applaud his ability to explain the matter more closely in a technical way that I cannot. but I can still see the effects it has and draw my own conclusions from it. Seems like you're too busy staring at the kernel and the "beautiful technical solution" to look for real, practical solutions.

[ 04-04-2002: Message edited by: Whyatt Thrash ]</p>

First of all, it's TaNenbaum, I truly hope, you haven't read a book about christmas or something... ;-)

While reading books and believing in yourself is certainly great, the ability to actively use your knowledge and draw useful conclusions is much more important. What we are discussing here is not something you can just take from the books. We are talking about strange Finder behaviour and how it can be explained and how (and why, and here the books will help you) it cannot. I actually hate to repeat myself, I think everything has been said and everybody should understand that by no means kernel funnels can be responsible for the complete blocking if you read a directory (on a SP machine).

About symptom fixes:
If a-&gt;b doesn't hold, it's useless to fix a(the "root cause"), you'd still have the b problem.


Now, if you really can't stop thinking about funnels, come up with some serious and detailed thread schedules that show when and why which funnel is held by which thread and why other threads are blocked and can't read another directory for example. It should be fairly easy to do, as long as you believe enough in your theory. Until then, please stop talking about the "root cause" and "symptom fixes".

123

Like 123, I hate repeating myself to horses wearing blinds, so I'll just say this.

[quote]Originally posted by AirSluf:
<strong>
Many, including you have said threads, well if a thread is stopped by a funnel lock that does exist--read the documentation--then no other threads can pass that point and the delay hits.</strong><hr></blockquote>

So why can other apps hit the BSD layer while the Finder remains locked? Answer me this and then explain how adding more funnels would solve the problem, when all access to the file system is obviously not locked...

You're staring so closely at the technical solution with the kernel, and how that must be right, and how YOU must be right that you're obviously totally blind to the effects of the problem and thereby shouldn't be able to draw informed conclusions on the cause of it.

I suggest it's time to just drop this discussion, cause you know you're right and me and 123 are convinced you're wrong, and it's too much a matter of prestige for you to ever consider the fact that you might be mistaken.

So you can lay off you condescending tone now and get on with your life. I know I will.

[ 04-05-2002: Message edited by: Whyatt Thrash ]</p>

[quote]But I'll laugh my ass off if I ever see anything about OS X adding any more of those un-needed funnels.<hr></blockquote>

You can laugh as hard as you want, just keep in mind that you don't have a reason. Funnels are not "un-needed" and adding more of them may even make sense as they are the "root cause" of all sorts of issues, BUT: the blocking Finder is just not one of them.

Okay, I've been following this thread since it started. Interesting stuff.

However, can anyone explain why a lack of "funnels" would cause the Finder to lock up with something like sorting a folder? Open a folder with several hundred items in it. Set it to list view. Sort by name. Done. Sort by date created. Done. Sort by version. Done. Sort by kind... wait... spinning disc... wait... wait... wait... done. Sort by name. Done. Sort by kind... wait... spinning disc... wait... wait... wait... done. Sort by date modified. Done.

See? I think you can only blame bad programming and lack of threading for that. The Finder *should* display the chasing arrows in the status bar if a window is waiting to do something like this. You *should* be allowed to do other tasks... not that something like this should freeze everything up for a minute or two.

[quote]Originally posted by starfleetX:
<strong>However, can anyone explain why a lack of "funnels" would cause the Finder to lock up with something like sorting a folder? Open a folder with several hundred items in it. Set it to list view. Sort by name. Done. Sort by date created. Done. Sort by version. Done. Sort by kind... wait... spinning disc... wait... wait... wait... done.</strong><hr></blockquote>

Damn, I hadn't even realized that was the cause of it. You were right, as soon as I set it to sort by name it read like a charm. Wonderful, man. I can browse my mp3-directory again. In a less practical way, but at least it's snappy.

Can't we all agree that Finder has issues, one way or another? It doesn't matter why anymore because in a month or two it'll be fixed:

Railhead Design:

Another 10.2 Seed Released
Another seed of Apples next major OS upgrade has been made available to select premiere developers. This latest seed sports drastic Finder revisions and major tune-ups in performance, sorting, auto-scrolling, spring-loaded folder action, contextual menu handling and the new print foundation (CUPS) is also being thoroughly pushed, jammed, and slammed into place by developers.

A few Apple people are also hinting that Apple will be showcasing the new additions coming to OS X 10.2 on their website within the next six weeks but Im still trying to get more solid information, though this makes (obvious) sense if we are to expect 10.2 to be released in July. But again, well have to see

[quote]Originally posted by Gambit:
<strong>Can't we all agree that Finder has issues, one way or another? It doesn't matter why anymore because in a month or two it'll be fixed:

Railhead Design:

Another 10.2 Seed Released
Another seed of Apples next major OS upgrade has been made available to select premiere developers. This latest seed sports drastic Finder revisions and major tune-ups in performance, sorting, auto-scrolling, spring-loaded folder action, contextual menu handling and the new print foundation (CUPS) is also being thoroughly pushed, jammed, and slammed into place by developers.

A few Apple people are also hinting that Apple will be showcasing the new additions coming to OS X 10.2 on their website within the next six weeks but Im still trying to get more solid information, though this makes (obvious) sense if we are to expect 10.2 to be released in July. But again, well have to see


</strong><hr></blockquote>

Well, Railhead didn't know much about Photoshop (his b85 was way off), so I don't know how good his sources are.

But the bit about Apple posting news about 10.2 on Apple.com in a few weeks sounds correct.

Apple has more or less confirmed that 10.2 will be showcased on WWDC May 6, and I guess that they will publish some info on 10.2 on Apple.com the same day or so.

This is childish.

I wish the finder was faster also. But Apple is doing a good job for working with a new kernel and code set they have never worked with.

Cocoa is the better API, but coding for it won't really explode until we get a true 64 bit archetecture. Carbon was originally created so developers could easily port OS 9 apps to OS X. Don't forget that.

But this flame war of a thread is is emberassing.

Finally, if you hate the finder that much, use Snax or another finder alternative.

[quote]Originally posted by GPTurismo:
<strong>This is childish.

I wish the finder was faster also. But Apple is doing a good job for working with a new kernel and code set they have never worked with.
</strong><hr></blockquote>

Actually, the engineers that are working on it were the ones who designed it. So they know it inside and out.

[quote]<strong>
Cocoa is the better API, but coding for it won't really explode until we get a true 64 bit architecture. Carbon was originally created so developers could easily port OS 9 apps to OS X. Don't forget that.
</strong><hr></blockquote>

Has has already been established, Carbon and Cocoa are designed to be *EQUAL* API's. There is no way in h ell that Adobe and the like are going to rewrite their apps in Cocoa, just because some *believe* that Cocoa is better than Carbon.

And would you please cite some examples as to why you believe that Cocoa is better?

[quote]<strong>
But this flame war of a thread is is emberassing.
</strong><hr></blockquote>

And fun

[quote]<strong>
Finally, if you hate the finder that much, use Snax or another finder alternative.</strong><hr></blockquote>

And I'm sure some are.

<a href="http://www.lowendmac.com/itc/010330pf.html" target="_blank">http://www.lowendmac.com/itc/010330pf.html</a>

<a href="http://www.oreillynet.com/pub/a/mac/2001/05/23/cocoa_vs_carbon.html" target="_blank">http://www.oreillynet.com/pub/a/mac/2001/05/23/cocoa_vs_carbon.html</a>

<a href="http://www.savannahmug.org/mmo/archived/cocoacarbon/cocoacarbon.html" target="_blank">http://www.savannahmug.org/mmo/archived/cocoacarbon/cocoacarbon.html</a>

<a href="http://maccentral.macworld.com/news/0101/04.macosx.shtml" target="_blank">http://maccentral.macworld.com/news/0101/04.macosx.shtml</a>

There are a few I could find real quick. I have more at home.

Carbon was created for a buffer for Developers to quickly port Classic apps to OS X. So basically, it is a "port" of the classic mac os API to run in a unix enviroment. Cocoa is pretty much Openstep, which is the upgrade to NextStep which is an off shoot of BSD Unix. The biggest problem Carbon is going to produce is when apple decides to take OS X to a true 64 bit platform. Since cocoa and most of the other enviroments and elements of OS X are Object Oriented, like 99% of other Posix systems, it can be easily upgraded to 64 bit, or scaled. This is the problem with standard c programming. All the code is compiled together, and dependent on itself. With Object orientated programming, you make different parts, and they work together to make the app. A good example, strictly for concstruction, and not durability etc, is making lincoln logs, (cocoa) and a tree (carbon.) With Lincoln logs, you can constantly rebuild your little house, and the base, which is say, 32 bit, you can swap out easily for a new base, 64 bit. With a tree, it constantly grows, and you can never rebuild a tree. And once it's root is established, 32-bit, to make it 64 bit you would have to completely cut down the tree. Also, with a tree, you can cut off limbs and have new ones grow. But it starts to weaken because of this, and if you ever have to take a big chunk out of the base, even if you patch it with wood cement, you eventually will have to brace the tree, and that tree is never really "whole" anymore.

With the lincoln logs, if one piece gets broken, you can simply replace it.

This is the problem Windows right now. They have built it in a "Tree" fashion. So it's going to be hard to make NT 64 bit without growing a new tree.

Posix systems and their apps can usually be made 64 bit, or even 128 bit easily, with simply taking out the base and swapping them. Look how fast red hat had a 64 bit version of their flavor of linux to run on itaniums.

Also taking full advantage of Open GL, Java, and many other elements of Mac OS X's posix system is the other great thing about Cocoa.

Plus, It's adobe's fault for them having these problems converting to a cocoa system. If they kept supporting irix they would have been able to quickly port it from their sgi verion to mac os x. The reason they quit supporting it is.... MICROSOFT.

Thats another great thing about object-c. You can make a program for linux and easily make it for darwin or cocoa. And thats whats so great. It's very open. Can you imagine games coming over to amc os x super fast if all the companies had to do is change certain parts of the code with object c?

Thats why companies that don't adapt are going to kill themselves or get left behind. Also it's why if apple doesn't get cocoa to be more fully supported by more than posix gurus and programmers, mac os x is good as dead. Why even waste our time on a UNIX system if your not going to take full advantage of it.

Why put a 500 horse power engine in a vehicle with a rear end gear ratio to pull. Sure you can pull houses off of their foundation, but when you can't go over 35 miles per hour whats the point? You're wasting gas, and you wasted a big investment.

GPT

Isn't Obj-C/Cocoa Mac OS X specific?

Not really. A lot of things are programmed in C/C++ in other POSIX sys's, but they are made mostly of components in the same way as Object C works. Not one big blob of code. Unfortunately, carbon enviroment wants one big blob of code. \

[ 04-12-2002: Message edited by: GPTurismo ]</p>

Also most of the higher POSIX systems use object based programming.

I read the links. And they all pretty much summed it up like this:

At this point, Carbon has some disadvantages. But so does Cocoa (Printing manager, anyone? It's CARBON!) As far as things like ScrollWheel support and moving the Preferences menu item, these are the programmer's job, not Carbon's. There is even Carbon Service support (buggy, but it's there). And finally, Mac OS X 10.2 should address most of the outstanding issues, so the two API's will be equal.

As far as the Lincolin Log/Tree analogy, couldn't Apple just rewrite the Carbon API for 64/128 bit and ask developers to recompile their apps? If not, why?

Because it's a lot harder than just asking nicely. re-writing code is a serious deal. And you can just strip out the code you want and replace it. Like the tree, all the code is dependent on each other, In the testing phase, when adding new pieces, you test it to make all the existing lines of code to work. Even all the code you couldn't strip. Carbon really isn't scalable either. Which means it wasn't designed to be upgraded. Which in turn means that the code was written to be 32 bit. In Object oriented programming, a compnonent determines bittage, and all the pieces look at that component to determine what they are themselves. In other wordsm you got to regrow the tree.

So which is faster, more reliable, and moreeconomical? Replacing a piece of houses in aneighbor hood, like the water meter, going through a forest and cutting chunks out of trees and patching them up and hoping they don't die, or regrowing a forest?

So if they are going to have to rewrite code, why not go ahead and rewrite it in Object C?

You aren't seeing the picture here. This isn't to be rude here. This is the problem with MS, and many other developers, and why us personal computer users are still 32 bit when people like SGI are 64 bit + for the past 10 years., and going 128 bit and even higher in the past few years. And it's not cost. Carbon was developed to be an inbetween Mac OS 9.x and Cocoa. It was to get apps to OS X quickly. The reason they constantly make Carbon more like cocoa is so they can easily make the apps jump to cocoa and then completely remove the carbon api. Cocoa is a true unix enviroment. So why keep using carbon when we talk about a UNIX system. Carbon is a simply a quick hyrbid. The owner of Realbasic defended carbon saying they are the same. But he didn't once mention the fact when OS X changes to true 64 bit, carbon is going to be scaled out because it can't keep up. It isn't a true Unix Enviroment.

Thats why apple is pushing for Cocoa. The reason so many pieces of apples code are in Carbon? Time, money, and laziness. Apple had to rush many elements of OS X to get it out, so they took their own short cut they developed for developers. The dock is cocoa, because it had to be to work smoothly. The reason why the finder is slow is because it's a hybrid/different language system windows manager on a POSIX system. To speed it up, and make it more smooth like the classic finder, they will need to make it cocoa. Plain and simple.

Trust me, we need to start getting people to go to cocoa, or when Windows goes 64 bit, us mac fanatics will be left in the dust.

"As far as the Lincolin Log/Tree analogy, couldn't Apple just rewrite the Carbon API for 64/128 bit and ask developers to recompile their apps? If not, why?"

So they can rewrite it AGAIN when it goes 256/512? and AGAIN when it goes 1024/2056, and AGAIN....

That starts to break compatibility, and creates problems., and slowsit down even faster.