On Mar 27, 2010, at 5:45 AM, Alexander Bokovikov wrote: > On 27.03.2010, at 1:59 PM, Ken Thomases wrote: > >> I can't see how this is either correct or incorrect >> from the point of view of OOP philosophy. >> OOP involves encapsulation, separation of concerns, >> polymorphism, etc. > > "separation of concerns" is just the case.
Except the timing does not impact on separation of concerns. The controller, the C in MVC, should be responsible for the process, whether it is initiated before the window is show or after. >> I would say it's the other way around: the window's appearance >> should be in response to the initiation of the process. > > My modal window's purpose is not just to show this initial process. It's a > dialog, which does something more complicated, but this initial process > should be completed to activate its subsequent functionality. Of course, we > could show this progress before the modal window appearance. But I don't like > it. Huh? I didn't suggest showing the progress before the modal window appears. I just suggested initiating the process before it appears, but even that was just because you seem hung up on the ordering of initiating the process vs. the window's appearance. >> Well, first, you should consider whether a modal window >> is the best design of your GUI. I would say there's a mild >> recommendation that they be avoided in favor of >> document-modal sheets and the like. > > It's not a document-based app. Well, I said "and the like". One doesn't need to have documents to have window-modal sheets. > This dialogue does some thing which can't be shared in time with other > functionality. It's just like Save File As... but more complex > > In MustDie all messages, addressed to the application, go through the window > procedure of the modal window. As I thought, you have a preconception. You're apparently coming from Windows. In Cocoa, there's no such thing as window procedures. > Modal window is the key window, the main window, and whatever you do you do > within it. OK. For what it's worth, you could just have an ordinary window. So long as it's the only window presented by your app at that time, and so long as all menu items are either relevant to it or disabled, then you don't need to run it as a modal window if you don't want to. > Therefore I don't understand why notifications should be queued in the "main" > loop while they can't be processed by the modal window messages loop. You keep saying that. You don't understand that notifications are not in any way affected by the event loop or the runloop. When some code posts a notification, the notification center immediately iterates through the registered observers and invokes their selectors. It does this synchronously. It does this without using the runloop. Notifications are not normally queued. (One can use NSNotificationQueue to queue notifications, and that can interact with the runloop, but that's not typically how notifications from the framework are handled.) Some events and runloop sources are indeed not handled in certain runloop modes, and the modal event loop runs in a different mode than the main event loop. This is what makes the modal event loop "modal". If the modal event loop processed all of the same events as the main event loop, then it wouldn't be modal -- the user would be able to do things outside of the modal window, like clicking on buttons in another window, or selecting menus not related to the modal window. So, I don't know how you expect that to work differently. But this has _nothing_ to do with notifications. As we saw with NSFileHandle, where necessary it is usually quite easy to ask for an event or runloop source to operate in the modal runloop mode. It's just not a big problem. It seems like you're inventing aggravation for yourself. Regards, Ken _______________________________________________ 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
