[Steve's Sanity]

Will Leopard's Finder Finally Menu Task?

Menu Task - (Def) The ability of a program to display visual updates to application windows, specifically, but not limited to, copy dialogs.

The Finder has always been deficient at this. It's really embarrasing from the geek's perspective to still see it. Btw, for the record, it's not a limitation of the Carbon environment because iTunes menu tasks quite ably.

So, will 10.5's Finder finally fix this issue?

[TETENAL]

What?

The Finder displays visual feedback during copy. I have a copy dialog with a progress bar.

[msuper69]

?

[seanc]

I don't get what you're on about either, care to elaborate?

[Chuckit]

Your username is misleading.

[siMac]

Yes.

[jasong]

Actually, the 10.4.7 update due any second now will fix this.

[Horsepoo!!!]

What happened to Steve's Sanity's sanity? He took it out with the trash. . .

[CharlesS]

I think what the OP was referring to was the fact that the progress bars and other interface elements don't get updated while you're using a menu. I just tried it, and the interface did indeed grind to a halt while I was holding a menu down. Why this would happen is beyond me. I'm not a Carbon developer, but my understanding was that Carbon Events is supposed to take care of things like this. Unless the Finder is still using WaitNextEvent(), which I would hope isn't the case...

[seanc]

Ah, now that makes more sense.

[Horsepoo!!!]

Originally Posted by CharlesS

I think what the OP was referring to was the fact that the progress bars and other interface elements don't get updated while you're using a menu. I just tried it, and the interface did indeed grind to a halt while I was holding a menu down. Why this would happen is beyond me. I'm not a Carbon developer, but my understanding was that Carbon Events is supposed to take care of things like this. Unless the Finder is still using WaitNextEvent(), which I would hope isn't the case...

This problem is old as dinosaurs. It doesn't matter if you're using a Carbon app, a Cocoa app, or a Goonygoogoo app, everything that isn't threaded (everything in the main thread) will grind to a halt if you're playing around in the menus.

Safari, Mail, iChat, Finder, iTunes, and a shitload of other apps exhibit this sad nature. I hope Apple does something about this.

Even your own Pacifist will grind to a halt if you click on a menu for things you haven't threaded. The registration nag screen that does the countdown simply stops counting down once you click on a menu.

If 10.5 doesn't fix this, I'll shoot myself. I've systematically reported this every new OS X release.

[macboy]

The one thing that has definately changed in the finder, is the little i (info) icon on the top bar - To get file size and things like that. Rest, we'll have to wait till the official unveiling August ..

[jasong]

Interestingly enough, Safari didn't always do this. http://forums.macnn.com/90/mac-os-x/187607/a-regression-in-panther/

[TETENAL]

Originally Posted by Horsepoo!!!

everything that isn't threaded (everything in the main thread) will grind to a halt if you're playing around in the menus.

Timers fire in the main thread (if you want them to) while menu tracking. Both in Carbon and in Cocoa. An app just must have to want to update its UI from such a timer. There's no need for multi-threading. Updating the UI from anything but the main thread is hairy anyway.

[Horsepoo!!!]

Originally Posted by TETENAL

Timers fire in the main thread (if you want them to) while menu tracking. Both in Carbon and in Cocoa. An app just must have to want to update its UI from such a timer. There's no need for multi-threading. Updating the UI from anything but the main thread is hairy anyway.

There shouldn't be a need but Apple's thread-unsafe handling of menu events kills any UI updating (or any action for that matter) done on the main-thread. Such is a fact of life right now. Like I've said, not only does the timer not visually update itself while in menus, it doesn't even count down. Same with Mail, if you hit the 'Get Mail' button but start playing in the menus before Mail has finished downloading new mail, it won't get that mail until you're out of menu events.

[TheSpaz]

I agree. I think the other processes should be moving no matter if your using menus or dragging files or moving scroll bars. Why would Apple do this... do you think this is on purpose so that the user feels at ease when they're using the menus they don't have to worry about their file downloading and finishing before they're ready.

Oh and I wish Apple would change the fact that when someone sends you a file in iChat, the Finder pops to the front to show you the file you just downloaded... annoying as hell.

[CharlesS]

Originally Posted by Horsepoo!!!

This problem is old as dinosaurs. It doesn't matter if you're using a Carbon app, a Cocoa app, or a Goonygoogoo app, everything that isn't threaded (everything in the main thread) will grind to a halt if you're playing around in the menus.

This is not correct. In Cocoa apps (and probably in Carbon apps too), all UI updating has to be done on the main thread. If another thread needs to update the UI, it needs to send a message to the main thread (in Cocoa, this would typically be done using -[NSObject performSelectorOnMainThread:withObject:waitUntilDo ne:], although you could also use an NSConnection). If you try to update the UI directly from a thread, there's a pretty good chance that the app will crash.

See below.

Even your own Pacifist will grind to a halt if you click on a menu for things you haven't threaded. The registration nag screen that does the countdown simply stops counting down once you click on a menu.

Whereas if you try pretty much anything else in Pacifist, it'll update while the menu is down. Loading the install discs, extracting files from a package, verifying an installation, loading the receipts for the kernel extension report - for all these things, the UI, progress bars, windows, etc., will all be updated while the menu is down, and while the actual work of loading the package or whatever might be happening in a different thread, all the UI updating is being done in the main thread. I should know, I wrote the app. And it does update, even with the menus down. So if some apps are stopping when the menu is down, it's not because menus tie up the main thread.

The bit with the registration countdown is interesting, and I don't know why it does that, but my guess would be that it has something to do either with the fact that the run loop is running in NSModalPanelRunLoopMode instead of the default run loop mode at that particular moment. I notice that in that case, everything does indeed stop (even my NSTimer, which is attached to the run loop for mode NSModalPanelRunLoopMode). My guess is that the Cocoa engineers figured that if an app had been taken over by a modal window, and most of the menus wouldn't even work, then it wasn't a great big deal to menutask in the middle of a modal session.

[Horsepoo!!!]

Originally Posted by CharlesS

This is not correct. In Cocoa apps (and probably in Carbon apps too), all UI updating has to be done on the main thread. If another thread needs to update the UI, it needs to send a message to the main thread (in Cocoa, this would typically be done using -[NSObject performSelectorOnMainThread:withObject:waitUntilDo ne:], although you could also use an NSConnection). If you try to update the UI directly from a thread, there's a pretty good chance that the app will crash.

See below.


Whereas if you try pretty much anything else in Pacifist, it'll update while the menu is down. Loading the install discs, extracting files from a package, verifying an installation, loading the receipts for the kernel extension report - for all these things, the UI, progress bars, windows, etc., will all be updated while the menu is down, and while the actual work of loading the package or whatever might be happening in a different thread, all the UI updating is being done in the main thread. I should know, I wrote the app. And it does update, even with the menus down. So if some apps are stopping when the menu is down, it's not because menus tie up the main thread.

The bit with the registration countdown is interesting, and I don't know why it does that, but my guess would be that it has something to do either with the fact that the run loop is running in NSModalPanelRunLoopMode instead of the default run loop mode at that particular moment. I notice that in that case, everything does indeed stop (even my NSTimer, which is attached to the run loop for mode NSModalPanelRunLoopMode). My guess is that the Cocoa engineers figured that if an app had been taken over by a modal window, and most of the menus wouldn't even work, then it wasn't a great big deal to menutask in the middle of a modal session.

Regardless of what the true reasons are...a ridiculously large number of apps simply stop doing (not just UI redrawing) what they're doing when 'menu tasking' (hence my apparently failed assumption that whatever's in the main thread gets put on hold.)

[Chuckit]

It's not that the thread is stopped, but the runloop switches modes. When you're using a menu, it goes into NSEventTrackingRunLoopMode. Thus, most aspects of the app are put on hold. It actually used to work the way you're thinking, but Apple changed it in either 10.2 or 10.3. So in Pacifist's case, the timer will need to be added to both NSModalPanelRunLoopMode and NSEventTrackingRunLoopMode if you want it to keep firing while menu tracking is going on.

[CharlesS]

Well, Chuckit, you appear to be absolutely correct. I added the timer for NSEventTrackingRunLoopMode, and now the countdown keeps on ticking when you're going through the menus. And of course, there is no threading involved in the nag screen whatsoever. So, Horsepoo, I have added this functionality just for you, and you'll see it in Pacifist 2.0.1 when it comes out. Of course, if you register the app, then you'll never have to wait for that countdown again, and that's even better, right?

[Big Mac]

The fact that iTunes menutasks properly but the Finder does not leads me to believe that the Finder is indeed still using WaitNextEvent. Perhaps Apple's engineers were too busy optimizing the code base for x86 to ever bother touching it.

[alex_kac]

So the question is (I'm not an OS X Dev), can Apple make your "fix" obsolete within the system without breaking anything?

[TETENAL]

Originally Posted by Big Mac

The fact that iTunes menutasks properly but the Finder does not leads me to believe that the Finder is indeed still using WaitNextEvent.

Actually iTunes is still using WNE. You can see it if you sample it.

As I said before, timers fire during menu tracking. It's the applications choice whether they want to make use of that or not. WNE or RAEL doesn't matter.

[Big Mac]

Originally Posted by alex_kac

So the question is (I'm not an OS X Dev), can Apple make your "fix" obsolete within the system without breaking anything?

I think in the aforementioned case of Pacifist, CharlesS did not apply a fix, as much as he modified the code in the accepted way in order to gain the desired result. Additionally, OS X's code base has (theoretically) stabilized with the releases of Panther and Tiger, so the core programmatic methods for achieving such basic results should remain constant.

Originally Posted by TETENAL

Actually iTunes is still using WNE. You can see it if you sample it.

As I said before, timers fire during menu tracking. It's the applications choice whether they want to make use of that or not. WNE or RAEL doesn't matter.

Interesting. So, which is fairer to say - Apple has so little regard for the Finder that it has failed to do something quite simple to solve the issue, or the problem in the Finder's case is more complicated than you've made it sound?

[TETENAL]

It's not complicated, but it requires intentional programming effort. They did it in iTunes to keep the clock and visualizers running and have iTunes advance to the next song while a menu is up. People would complain a lot if that stopped during menu tracking. In Finder it was not deemed too important to do this for the progress dialogs. The menus are open a short time only anyway and the user is looking at them then and not at a dialog box. What's important is that the copy continues and it does. You may call this "little regard for the Finder" if you want to. I just wanted to point out that it is not a Carbon vs. Cocoa nor a WNE vs. RAEL issue.

[CharlesS]

Originally Posted by TETENAL

It's not complicated, but it requires intentional programming effort. They did it in iTunes to keep the clock and visualizers running and have iTunes advance to the next song while a menu is up. People would complain a lot if that stopped during menu tracking. In Finder it was not deemed too important to do this for the progress dialogs. The menus are open a short time only anyway and the user is looking at them then and not at a dialog box. What's important is that the copy continues and it does. You may call this "little regard for the Finder" if you want to. I just wanted to point out that it is not a Carbon vs. Cocoa nor a WNE vs. RAEL issue.

Well, this certainly seems to be true for timers firing, but for a lot of other things it certainly seems like a lot is done for you in this regard. For Pacifist, the registration countdown stopped when menutasking, but all the progress bars and other such things in the app have always worked while the menus were down, and I never needed to expend any extra programming effort to make this happen - it seemed that Cocoa handled it automatically (and I thought that Carbon Events did this also, but in light of recent revelations in this thread, I'm probably wrong).

[TETENAL]

Control throbbing works in both correctly during menu tracking (I checked in Finder copy and Safari download progress bar), but the actual progress is not displayed in both (checked in those same dialogs). So there isn't much of a difference. It can be done in both, but I will admit to you that it is somewhat more work in Carbon.

[CharlesS]

Originally Posted by TETENAL

Control throbbing works in both correctly during menu tracking (I checked in Finder copy and Safari download progress bar), but the actual progress is not displayed in both (checked in those same dialogs). So there isn't much of a difference. It can be done in both, but I will admit to you that it is somewhat more work in Carbon.

Well, the thing is that I don't know what the Safari coders are doing, but I do know that Safari sometimes doesn't do everything in the standard Cocoa way, in order to make things a little faster.

All I know is that in Pacifist, the progress is displayed during menu tracking, and that I didn't do anything special to make that happen.