[Development] Qt Quick Controls Dialogs -- enabled state of the standard buttons (API choices)

[Curtis Mitch]

From: Vladimir Moolle [mailto:vmoolle at ics.com]
Sent: Wednesday, 26 August 2015 12:01 AM
To: Rutledge Shawn <Shawn.Rutledge at theqtcompany.com>
Cc: Filippo Cucchetto <filippocucchetto at gmail.com>; Curtis Mitch <mitch.curtis at theqtcompany.com>; development at qt-project.org
Subject: Re: [Development] Qt Quick Controls Dialogs -- enabled state of the standard buttons (API choices)

Hi, thank you all for the comments and suggestions you’ve left.  They’ve helped us come to a consensus as to what is desired for the future API.  We’d like to make the following proposal for the new version of Dialog.

1 .  Upon collective agreement, the main use case becomes something like:

Dialog {
    ButtonBox { // probably, no need to prepend the name with Dialog,
                // provided ButtonBox ends up in Dialogs module
                // (and not in Controls nor Layouts modules)
        Button {
            ButtonBox.standardButton: StandardButton.Ok
        }
        Button {
            ButtonBox.standardButton: StandardButton.Cancel
          enabled: <some binding expression>
        }
}


This adds the desired ability to govern buttons’ enabled state with bindings, and also to apply styles, etc. (all without the clutter of “button delegates” as proposed in #6 of the last week’s e-mail, and with no proxy objects or button getters).

2 .  One nice feature of above API could be possibility to use completely custom items for buttons, as long as they specify a standard role via the attached property (and have a clicked signal):

Dialog {
    ButtonBox {
        MyCustomButton {
            // has a clicked() signal (otherwise a warning is emitted by ButtonBox)
            ButtonBox.standardButton: StandardButton.Cancel
        }
}

3 . Moreover, it could be possible to allow the user to add buttons lacking any standard behavior to the ButtonBox:

Dialog {
    ButtonBox {
        Button {
            // would require adding StandardButton.Other to the StandardButton flags
            //   (so that buttons could be differentiated from other children of ButtonBox)
            ButtonBox.standardButton: StandardButton.Other // Default value for this property
            onClicked: <custom handler>
       }
}

4 . Given the above, parenting (and laying out manually) arbitrary other items becomes simple, too:

Dialog {
    ButtonBox {
        MyCustomBackground {
            // lacks ButtonBox.standardButton property, and is not laid out by ButtonBox
            anchors.fill: parent
        }
        Button {
            ButtonBox.standardButton: StandardButton.Ok
       }
}

5 . It may be beneficial to deprecate the current standardButtons-based API in favour of the new one (in Controls 3?), and opt for manual (rather than automatic, with a possibility to discard) ButtonBox insertion into the dialogs -- this comes at a cost of a couple extra braces, but makes code intent more explicit, and allows for trivial parenting to the ButtonBox (when it is necessary, as in #4 above).

Additionally, another, simplified item could be added, leveraging the new API to implement the old one and ease porting the existing code.

Best regards, Vladimir

What is the benefit of adding ButtonBox over just adding a Dialog.buttonRole attached property?

It’s also a bit scary that there are now three ways to add buttons to a dialog:


-    standardButtons

-    Declaring them as children (manual layout)

-    Declaring them as children of a ButtonBox (automatic layout)

By the way, I’m not saying that the attached property approach is any better in this regard (you can replace the last bullet point with it and it still applies), I just think it’s growing quite complex.

Can’t we just deprecate standardButtons and tell users that ButtonBox or Dialog.buttonRole is the new way of declaring standard buttons?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150826/67ecffa6/attachment.html>