Grrr. OK, I’ve got a beautiful progress-monitoring solution that works lovely for background threads with minimal impact on that thread (or for work that is done in chunks on the main thread), and it’s doing great service for tracking a lengthy file open (as a side note, I’ve tracked down some inefficiencies that have reduced my lengthy file open from 3 minutes to about 5 seconds for the test case I’m using, but anyway…). With this, opening files concurrently becomes a far nicer user experience.
Now I discover that for a Revert operation, NSDocument invokes -readFromFileWrapper… synchronously on the main thread, despite me returning YES from +canConcurrentlyOpenDocumentsOfType: I’ve basically given up on making my progress classes work in this situation - it just seems too hard and too kludgey. The only way that works with any decent cooperation is presenting the dialog as a modal session and running it using runModalSession:, but this is a completely different architecture to the usual case of running the dialog modelessly as a natural part of the main run loop, and it’s a royal pain to set up and tear down properly. Can anyone think of a solution to this? Just not showing progress for Revert is one of course, but for a huge file it blocks the main thread for as long as it takes and the user gets no proper feedback, just a beachball. I guess I could spin off my own thread, but that might not play nice with NSDocument which heaven knows is finicky and troublesome enough as it is. It’s not clear I would be able to hook back into NSDocument at the right place when my threaded file read completes. I wish the frameworks were a bit more consistent about this - if I say I can open on a background thread then it would be nice if that meant ALWAYS open on a background thread, but no. Any ideas? —Graham On 12 Nov 2013, at 8:23 pm, Graham Cox <graham....@bigpond.com> wrote: > Probably true, but something Jens said got me thinking, and in fact I have > added a solution that’s so easy I dunno why it didn’t occur to me before - > instead of the worker thread driving progress, get the progress to poll the > worker thread. Turns out that this is so simple my worker thread is doing > far, far less than it was to support progress, and the UI cannot go any > faster than a rate I set, and nothing is queued at all. Simples! (and thanks > Jens for the inspiration). _______________________________________________ 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
