[Development] Should a QMessageBox (or other dialog) NOT dismiss itself automatically when the Help button is pressed? (QTBUG-34566)

[Oleg Shparber]

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 <apoenitz at t-online.de> 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
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



-- 
Oleg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20141022/19ea56a7/attachment.html>