On Nov 8, 2013, at 11:17 AM, Graham Cox <graham....@bigpond.com> wrote:
> The more philosophical question is why do this on the main thread? > > Part of it has to do with keeping my options open - I can use a thread or > not. The situation is in fact handling the file read for NSDocument, so > setting +canConcurrentlyReadDocumentsOfType: selects whether a thread is used > or not. However, I’ve discovered that if you do allow it to use a thread, > there are two unpleasant usability side effects. Well, you can't call -runModalSession: from a background thread, so you still have two code paths. > > If the file is small and can be read quickly, it really doesn’t make much > difference either way whether it’s threaded or not. But if it’s a large file, > there may be some time (even minutes) between clicking ‘Open’ in the > NSOpenPanel and the document opening its window. During that time, there is > no feedback whatsoever that anything is happening. It acts, for all intents > and purposes, as if the ‘Open’ click was ignored. Because the app remains > responsive, you might try again, and now you have the same file being opened > on two threads (unless something takes care to prevent this with NSDocument, > I haven’t investigated). The user simply thinks your app is broken. But then, > bang, the document windows open unexpectedly at some indeterminate future > time. It was trying to mitigate this terrible lack of feedback that motivated > having a progress indicator for file opening. I would seriously consider implementing this approach. My general idea is to subclass NSDocumentController and put up a progress panel before loading the document. Unfortunately it doesn't look like NSDocumentController makes this easy. You'd have to put up the UI in -openDocumentWithContentsOfURL:display:completionHandler:, but you won't know if NSDocumentController has determined it actually needs to create a document until the completion handler executes. One workaround would be to delay-perform setting up the progress panel and tear it down in the completion handler, but that would only work for types that are opened asynchronously (the panel would never appear for synchronous loading). A more elaborate solution involving overriding -makeDocumentWithContentsOfURL: may also be required. This happens to be a problem I need to solve sometime soon, so thanks for getting me to chew on it. > But in fact, simply not opening them concurrently and just blocking the main > thread while they open is much better from the user’s point of view - they > can tell that something is happening, even if they have to wait until it’s > done. The app may be unresponsive, but at least it doesn’t seem broken. And > having the app responsive while a file is opening is of minimal benefit it > seems to me - the user wanted to work on another file, that’s why they opened > it - so the time waiting for this file to open on a thread is not time that > is likely to be fruitfully spent editing some other file. There are some people who live in a certain app; they're the ones I think about when considering asynchronous loading. > > The other reason, which is more surprising, is that my assumption was that > the Versions browser would work better if the documents were opened on a > background thread. The reality is, it works far worse. It seems to ask the > app to start decoding as many files as it can when you enter Versions, and > pretty soon my machine is blowing its fans and is so stuttery it’s impossible > to use. When the document is opening its files on the main thread, this > doesn’t happen - it seems Versions is happy enough to let it open one file at > a time and only goes back to the app to decode a file as it is displayed. This sounds pretty bad. Have you filed a Radar? In e meantime, you could listen for NSWindowWillEnterVersionBrowserNotification and selectively disable concurrent document loading. --Kyle Sluder _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
