On Jul 17, 2014, at 6:35 AM, Graham Cox <graham....@bigpond.com> wrote:
>
> On 17 Jul 2014, at 4:01 am, edward taffel <etaf...@me.com> 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
>
graham,
thanks again for your copious comment, & i agree w/ everything you say! (have
you actually gotten similar to work?)
> There's absolutely no reason you can't show windows before a main document
> window is opened.
i hope so: i’m obviously missing something.
> While splashscreens are generally discouraged, what's wrong with a modeless
> progress panel that floats above normal windows?
nothing: the splash was just a test to see if NSApplication would put up a
window before NSDocument kicked-in—i don’t need it.
> 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.
agreed!
> 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.
as i mentioned, i moved panel startup to application delegate init; & to avoid
any main thread contingency i’ve tried:
- (id)init {
if(self = [super init]) {
[self performSelectorOnMainThread:@selector(startUp) withObject:nil
waitUntilDone:YES];
}
return self;
}
& this IS definitely called before NSDocument methods: the panels still do not
expose: any thoughts here? (this is where i must be missing something, no?)
> 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:].
i’ve tried returning both YES & NO: no affect to exposure timing.
> 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.
i’ll revisit progress after i get some interface up, adapting ideas you
expressed before.
>
> --Graham
thanks again & best,
edward
_______________________________________________
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
