It has been proposed that in QtQuick.Dialogs, the Help, Apply and Reset buttons should not dismiss any dialog automatically. I agree conceptually, but the issue is that to be completely consistent, we need to change the behavior of QMessageBox (and various native dialog implementations) to match. The desire to be consistent is actually the reason that the QtQuick.Dialogs MessageDialog always dismisses the dialog when any button is pressed (except for the Show Details… button, because that only makes a self-contained visual change inside the dialog, and doesn’t emit a signal).
(Just to review: if you instantiate a MessageDialog in QML, you might get a native dialog if it’s available (only on Android so far); otherwise if you are using a QApplication, widgets are available, so you will get a QMessageBox; only if neither of those options work, will it fall back to the QML implementation in DefaultMessageDialog.qml. So you are more likely to get a message dialog which does dismiss on Help, even after applying patch 97372 below.) When a message dialog is open, and a user presses the Help button, what behavior provides the best usability? My opinion is that if some help is going to open up in another window, it would be nice to be able to read the message dialog and the help side by side, especially if the purpose of the help is to clarify a choice that the message dialog is providing. If pressing the help button dismisses the dialog, it is then too late to make the right choice, so the help is not particularly useful. QDialogButtonBox can have a help button too, but in that case it is up to the application developer to connect to the signals (accepted, rejected and helpRequested) to dismiss the dialog or do something else. Whereas in QtQuick.Dialogs.Dialog, the buttons are built-in (another design decision that we could re-visit), so the behavior is also built-in. To be consistent with MessageDialog, Dialog also dismisses itself automatically when any button is pressed. (That case is worse, because you could also have an Apply or RestoreDefaults button, and you probably don’t expect the dialog to be dismissed when those buttons are pressed either; but it does.) On the other hand, if the message dialog is modal, the user may not be able to interact with the help. But maybe the help is simple enough to fit on one page, so being able to see it is enough. And if we change the behavior of such an old dialog as QMessageBox, someone will eventually complain, of course. But if the developer wants the help button to dismiss the dialog, it’s also not very hard to connect to the buttonClicked signal to do that. So I think maybe since it’s a behavior change, we should wait until 5.5; the purpose of this mail is to ask if anyone has an objection to changing it at all. Or on the other hand, if anyone has been annoyed and needed to work around this problem for ages already. ;-) https://codereview.qt-project.org/97372 is the patch for QtQuick.Dialogs, which IMO should not go in until we can ensure that the behavior is consistent regardless of dialog implementation. https://codereview.qt-project.org/97814 adds Help buttons to a couple of the widget examples, to demonstrate the differing behaviors. The code which closes the dialog when a button is pressed is in QDialog::done(int r), so I guess that is where it will need to be made conditional on the role. Another related issue is that we should probably be using the special Help button on OS X: https://bugreports.qt-project.org/browse/QTBUG-34565 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
