modal dialogs and Quit problem

[Barry Levine]

(alex wrote):
> Can you explain what you mean "permitting a modal dialog to be
> interrupted"? If Rev's modal dialogs are somehow not really modal that
> would of course I would be concerned too... I just don't understand the
> argument now. I just skimmed through bug #536, and still don't get it.

Alex,

Okay; fair question. By definition, a "modal" dialog box requires the 
user to dismiss it before -any- other activity can proceed within that 
application. To quote from the Rev docs: "The modal command pauses the 
running handler until the modal dialog box is dismissed."

The "ask" and "answer" commands are also modal. Again, to quote the 
docs: "Use the ask command when a handler needs to get information from 
the user before continuing." and "Use the answer command to get 
information or a confirmation from the user before continuing. The user 
must click one of the buttons to dismiss the dialog box."

There is no program running on the Mac (or Windows, for that matter) 
following the Human Interface Guidelines that would permit a modal 
dialog box to be interrupted unless it was highly specific and 
backtrackable; I'll suggest the "Print" dialog in Windows and Mac which 
has potentially many buttons to bring up little "sub-dialogs" about 
"options" or "printer setup" issues. However, in this case, the 
sub-dialogs return you to the "main" dialog and back out to the app in 
a "last in - last out" fashion. You would never be permitted to select 
"Quit" while in the middle of such a dialog (or nest of dialogs). Look 
at Excel, Word, PowerPoint, AppleWorks, Final Cut, Mail, Explorer, 
Communicator, Toast, Nero, Entourage, Outlook, you name it. It's just 
plain wrong and violates important rules about user expectations and 
leading the user down the path of least danger.

Consider this scenario:

You've created a word processing application. The user selects "Save"  
and you present a modal dialog to facilitate the saving. However, Rev 
permits the user to then select "Quit" and the application will quit 
without saving the document. Okay; so you add a little shutdownRequest 
handler to confirm the quit action. It would still occur while the Save 
dialog was present! Can you think of -any- application that would 
permit you to quit in the middle of such a dialog without first 
dismissing it? It's absurd.

In the case of Rev for OSX -and- Windows, it is possible to select the 
Quit command and have a shutDownRequest execute while you are in the 
middle of a modal dialog ("ask" or "answer" or even "open stack 
modal"). In other words, the "modal dialog" is not modal at all! If you 
are not forced to first dismiss the dialog, it's not modal. (Read that 
sentence again.) You can't have it both ways.

So I hope you really mean it when you say that you "would be concerned 
too" if the modal dialogs are "not really modal" because I have shown 
you that they are, indeed, not modal by the only standard that counts: 
Can you do something else that subverts the intent of the modal dialog 
while the modal dialog is present? If so, it's not modal. Can you nest 
modal dialogs? Of course; but you must dismiss them in a last in - last 
out method (as in the "Print" dialog discussed above). In Rev's case, 
there is a routine missing that screws up how an app is supposed to 
behave.

Now, someone wrote (and I don't remember who) that it's the developer's 
responsibility to disable the Quit menu item. Fair enough. Show me how 
that can be done in OSX and I'll have a workaround. But the ultimate 
responsibility to get this right rests with the Rev folks.

Regards,
Barry