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

André Pönitz apoenitz at t-online.de
Wed Oct 22 21:34:17 CEST 2014


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.



More information about the Development mailing list