Originally, I have proposed that patch in response to a question on StackOverflow on non-intuitive Dialog behaviour. I thought it was just a bug fix, and didn't check if QtWidgets behave differently.
If such change is not suitable for Qt 5.x, then, I'd like to suggest a property that disables automatic dismissal of a dialog for all button roles. That would allow users manually control behaviour according to their needs. In Qt 6 it would be possible to change the default behaviour without worrying about breaking user apps. On Wed, Oct 22, 2014 at 12:34 PM, André Pönitz <[email protected]> wrote: > On Wed, Oct 22, 2014 at 01:28:38PM +0000, Rutledge Shawn wrote: > > 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.) > > If I understand that correctly we don't need to change the behaviour of > QMessageBox _in general_, but we want to change it when used as fallback > driven from QML code. > > That seems solvable. The situation "Runs as fallback from QML" is > discoverable before the button is clicked, either directly in the message > box implementation, or passed to the message box, e.g. by means of an > additional bool property with "official" setter, some magic dynamic > property, or similar. > > > 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. > > It's not hard, but needs a code change in the application. > > A promise of binary compatibility is pretty much useless if behaviour > changes require extra code on the application side to cover up. > > > So I think maybe since it’s a behavior change, we should wait until 5.5; > > 6.0... > > > the purpose of this mail is to ask if anyone has an objection to changing > > it at all. > > Of course I object to behaviour changes of Widget applications based solely > on QML convenience considerations. I do not object to a solution that > provides convenience to the QML side and offers an opt-in to the changed > behaviour, or simply keeps the existing behaviou on the Widget side. > > Andre' > > PS: I really appreciate your asking. > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development > -- Oleg
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
