Am 22.10.2014 um 15:28 schrieb Rutledge Shawn: > 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.
+1 > > 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 > _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
