Re: Getting mouse clicks when the main loop is busy
Re: Getting mouse clicks when the main loop is busy
- Subject: Re: Getting mouse clicks when the main loop is busy
- From: Kyle Sluder <email@hidden>
- Date: Sat, 09 Nov 2013 10:39:03 -0800
On Nov 8, 2013, at 11:17 AM, Graham Cox <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden