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

[Robert Löhning]

Am 22.10.2014 um 21:34 schrieb André Pönitz:
> 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.

IMHO closing a message box when the user clicks "Help" isn't a good idea 
in many cases. No matter whether QML is involved or not.

It might have a small advantage if the message box just presents a short 
informative text and an "OK" button. "Help" might then lead to some 
further info and there's no need to keep the message box open. This 
raises the question, though, whether showing such a message is helpful 
at all.

As soon as the message box offer a Yes/No or OK/Cancel alternative, 
closing it on "Help" seems wrong to me. I would expect the "Help" button 
to help me, to explain whether I should click "Yes" or "No". But that's 
pointless if these buttons are gone then.

> 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
>