Sounds like what we've got - when you start a virtual machine, asynchronous things happen and some of them generate dialogs. Some dialogs are just informative, some need a response. We've considered things like merging content when a dialog appears while another is up but what if dialog A is an alert, nicely self-contained, and dialog B is a custom sheet? So we queue up the dialog-info events and manage dialog dismissal so that if there's another one in the queue it'll appear when the current one is dismissed. It's not ideal but the times when they queue up more than one or two deep are rare enough not to be too much of a problem.
It would be nice if there was some sort of built-in combining stack, especially for the info-only dialogs, the way starting multiple file copies in the Finder gives you one window with multiple sections instead of multiple windows. ----- Original Message ----- From: "Oleg Andreev" <olega...@gmail.com> To: "Graham Cox" <graham....@bigpond.com> Cc: cocoa-dev@lists.apple.com, "Gregory Weston" <gwes...@mac.com> Sent: Wednesday, April 27, 2011 6:35:39 AM Subject: Re: Stack of NSWindow sheets I'll clarify what I meant. Normally, user will see only one sheet at a time. There won't be any sort of step-by-step sheet switching within a single task (like in Xcode 4 when creating a new file). The only issue I'm trying to solve is presenting a username/password dialog when it was invoked by a background task (not a direct user action). And since I may have several such background tasks running, I can potentially present several dialogs at once. Again, normally you'll see no dialogs at all (when the password is already stored in keychain) or a single dialog when a new repository is added or the password was changed. But I should have a nice fallback for a case when several dialogs get popped out. With floating modal windows it is not a problem: they live independently from each other. But floating modal windows look awful, so I want to use sheets. And to present them correctly, I need to maintain some sort of a queue for these sheets. On 27 Apr 2011, at 14:58, Graham Cox wrote: > I've seen an app that uses a stack of sheets in this fashion, and it's a > horrid, barely usable mess. It's a Microsoft app, though I forget exactly > which (and it may have been fixed, as this was quite some time ago). > > The problem is that the user either has to remember the "path" that led them > through to the current sheet in order to make sense of all the sheets that > pop-up as the stack is retraced, or else they do not, and the result is just > an utter confusion of sheets coming and going. > > My 2ยข worth is with the suggestion to think again. > > --Graham > > > On 27/04/2011, at 8:49 PM, Gregory Weston wrote: > >> I think the notion of a "stack" of sheets is bizarre. In the very rare >> scenarios where multiple sheets are used to accomplish something, I've never >> seen them presented as anything other than a strict sequence. When sheet N >> is dismissed, if more information is needed sheet N+1 will be presented. >> When sheet N+1 is dismissed, the user is shown the unobstructed window. When >> you say "stack" I infer that you intended to re-show sheet N. >> >> <http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Sheets/Tasks/UsingCascadingSheets.html%23//apple_ref/doc/uid/20001046-BABFIBIA> >> >> I should also say that having used OS X since the public beta I've rarely >> seen 2 sheets, and never 3 in a sequence. It might be a good idea to revisit >> your UI plans. Perhaps you can use fewer sheets but with optional parts akin >> to the print job sheet. > > _______________________________________________ > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/oleganza%40gmail.com > > This email sent to olega...@gmail.com _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/lrucker%40vmware.com This email sent to lruc...@vmware.com _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
