@danwood NSDictionary uses -isEqual:, but it sounds like maybe you're mutating your key after the dictionary copies it.
@ivanski And I think it's revealing if that's not available in 64-bit. Anyway, thanks for listening.
@ivanski Perhaps we can agree that no one would have said anything if you'd stuck with the wristwatch.
@ivanski Here's another user (Miguel H.): http://blogs.adobe.com/j...
@ivanski It's becoming non-standard. I take you at your word regarding intent, but users interpreted it as a mask for unresponsiveness.
@ivanski You're reinventing something that's being phased out.
@ivanski If you've read Buxton, you've read Jesper, who I agree with.
@ivanski Igot is looking at this from a higher level. If you can't handle user events (like clicking), the normal animation is SPOD.
@ivanski For me it goes directly to the dialog. Anyway, I don't think iTunes showing a watch is a good argument for you to invent a cursor.
@ivanski iTunes doesn't change the cursor as you suggested.
@ivanski Users care about what they can do, not a technicality where you are minimally responding to events. Please see Pierre Igot’s post.
@ivanski If you think the HIG suggests something that none of the standard apps do, I don't think the error is with those apps.
@ivanski Yes, it looks like "unresponsive but trying to hide SPOD." I wouldn't cancel in the first 2s. Beyond that, show a button.
@ivanski It doesn't say immediately. It says to provide “useful information” if the user would otherwise see the SPOD.
@ivanski Sure, they'll figure out the general idea. And think it looks a little odd.
@ivanski If responsive, I should be able to click on stuff, which means it should show the arrow. Cursor w/ no hotspot looks unresponsive.
@ivanski If less than 2s, no need for progress bar or canceling, and no SPOD. If more than 2s, progress bar, cancel button, arrow cursor.
@ivanski It's potentially confusing because no other Mac apps have ever repurposed this control as a cursor.
@ivanski The busy cursor is no longer a standard Mac idiom. We have arrow and SPOD now. For just 1s, let the OS auto-switch between those.
@ivanski If you're just avoiding a quick flash, I wouldn't bother changing the pointer at all. Otherwise, real progress would be useful.
@ivanski I think it would be nice to have a non-modal window with a determinate progress bar to show the progress opening a large file.
@ivanski I think iTunes is generally an example of the old ways of doing things. It has lots of modal dialogs, for example.
@jasperhauser (2) If I give it one file, I'd like to be able to choose from previous versions in Git to diff against.
@jasperhauser (1) Ability to edit the files, or at least accept/reject changes and merge.
@ivanski Yes, I no longer think the running dog is appropriate for Fetch. Associated w/ window, so use progress indicator in that window.
@ivanski Also, the HIG says that if you use a custom cursor it should indicate its hot spot, which the wristwatch doesn't.
@ivanski The HIG has a screenshot showing a progress window for opening a document. The wristwatch was in the OS 9 HIG but was removed in X.
@ivanski Final Cut Pro is a Carbon app and well-known for using non-standard interface elements.
@ivanski I don't think FCP is an interface standards bearer.
@ivanski When does BBEdit use the wristwatch? I see it SPOD when opening a large file.
@ivanski Precedent from Apple (e.g. iWork) is to show a progress window. Another option would be to use the Dock icon.
@ivanski Perhaps there's a good reason Apple removed the wristwatch cursor.