I think you're thinking about the problem too generally. The workflow manager is probably going to need to understand that the plugins it's running can have encounter exceptional conditions. Therefore, there should be a mechanism by which your processing plugins can inform the workflow manager of these exceptional conditions.
Whether the workflow manager then runs the NSAlert itself, or waits for the plugin to do so, that "paused" state is now captured by the workflow manager, and there is no need to consult AppKit about "the currently running NSAlert." In general, I think it's a bad idea to let plugins usurp the runloop of their hosting application, as would running an NSAlert from within a plugin. Better for the host application to manage this state explicitly. --Kyle Sluder On Mon, Dec 3, 2012, at 10:10 PM, Brad O'Hearne wrote: > Kyle, > > Thanks (I think). I asked the question as simply as I could without > convoluting it with quite a bit of complexity, which would probably lead > more to theoretical discussion rather than the specific issue. But since > you want a more involved description of the problem, I've developed a > processing framework that facilitates workflow by sequentially processing > workflow plugins. All plugins are agnostic of one another, and the > workflow framework is agnostic to the function of the plugins. This > workflow framework dynamically becomes whatever app I want it to be, just > by changing the plugin stack that the workflow framework processes. > > There are some interesting design questions that arise about > responsibility of processing, whether the workflow manager merely > provides certain state information to a plugin, and makes each plugin > handle the condition, or whether the workflow manager imposes itself on > the process. The particular manifestation that this question was > addressing is if a plugin presented a modal alert which the user had not > yet dismissed, when the workflow manager needed to present its own modal > alert, what approaches existed to handle this. > > Very similar questions exist between OS and apps -- when does the OS > merely provide info to an app (which passes responsibility for handling > to the app) vs. when does the OS impose itself on the app and overrule > its UI and processing. > > That's the idea...pretty oversimplified here. But that is what was behind > the question. If an app could easily request a reference to any NSAlert > that was currently being displayed, it might suggest an alternative to > handling it. Presently, each plugin has to handle dismissing its own > potentially displayed alerts when the workflow manager decides it needs > to display its own alerts, and the workflow manager effectively messages > the plugins by virtue of pause and resume lifecycle methods on plugins. > > Thanks, > > Brad > > Brad O'Hearne > Founder/Lead Developer > Big Hill Software LLC > http://www.bighillsoftware.com > > On Dec 3, 2012, at 10:10 PM, Kyle Sluder <k...@ksluder.com> wrote: > > > On Mon, Dec 3, 2012, at 05:13 PM, Brad O'Hearne wrote: > >> Hello all, > >> > >> Is there a way to get a reference to the currently displayed modal > >> NSAlert, or to be able to globally determine if a modal alert is > >> presently showing in a Cocoa app, though you have no knowledge of where > >> in the app it originated from? > > > > If you need to know this, your architecture is almost certainly screwed > > up. > > > > What are you actually trying to accomplish? > > > > --Kyle Sluder > _______________________________________________ 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
