On 17 Jul 2014, at 4:01 am, edward taffel <[email protected]> wrote: > some of you may recall a previous thread of mine: ‘showing load progress for > autosaved documents’; this is a recast version. > > from what i can discern, in the base case, application windows do not show > until autosaved documents have loaded, which makes it difficult to show load > progress on these. i thought to try a good-old splash window, the simplest > possible, i.e. ‘Visible at Launch’ checked, a property of the application > delegate: indeed, this does not appear until the autosaved documents are > shown—as was the case w/ the programmatically created window previously tried. > > in particular, i should like to put-up some of my app’s panels before > NSDocument starts loading documents: has anyone had any success along these > lines? is there a way to defer the opening of documents (autosaved, launch > via double-click or drop on the dock icon) until some app windows have > exposed? or, alternatively, is there a point during app launch prior to > NSDocument tasks to put up some windows?—the earliest point i can conceive is > application delegate init, but no luck here either. > > all comment greatly appreciated, > edward
There's absolutely no reason you can't show windows before a main document window is opened. While splashscreens are generally discouraged, what's wrong with a modeless progress panel that floats above normal windows? If you are opening multiple documents, and you have implemented something like we discussed last time, this is probably the best UI to go with anyway - if you wanted to rely on sheets attached to each document window, well, you'll only be able to see the topmost, because others will be occluded by it (and that's if they appeared before the document was loaded, which isn't the case). Note that the app has long been launched (in CPU terms) by the time the first document is opened, even if double-clicking the file was what launched the app. The key to making anything like this work is to realise that all your UI stuff (showing and drawing windows) MUST happen on the main thread. If it's blocked (because it's synchronously opening a document for example) then you won't see anything unless you take that into account. But, as we went through last time, the best approach is to allow documents to be opened on threads, and poll their progress from the main thread. That way, you can just go ahead and open the window, add the progress view(s) to it you need, and drive them along using a simple timer. You can prepare your progress window at launch time, or do it lazily when the first progress view is needed (when the document opens), but whatever you do, make sure it is the main thread that is asked to show and draw that window, and you should be fine. You generally don't want 'visible at launch' for windows, because something should be in charge of the window (its controller) and that should be responsible for making it visible. I can't see any reason why you are unable to show panels before documents start getting opened, unless the main thread is blocked. So opt-in to background document opening and let the main event loop idle while documents are opening, and then there shouldn't be any tricky stuff needed. It sounds like you're trying to workaround the fact that the main thread is blocked by deferring opening (on the main thread) when there's already a built-in solution to that which requires that you return a very simple flag from your document class: +[NSDocument canConcurrentlyReadDocumentsOfType:]. Of course, that means that your documents do actually have to be able to concurrently read the file, i.e. be thread safe. As long as that's true, the UI aspects of this should be straightforward. Your users will thank you as well, because it will mean your app appears a lot more resonsive while opening lengthy documents, and if you allow your progress views to include a cancel button, even cancellable during a file load. --Graham _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
