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

[Vladimir Moolle]

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


On Mon, Aug 24, 2015 at 10:41 AM, Rutledge Shawn <
Shawn.Rutledge at theqtcompany.com> wrote:

> On 22 Aug 2015, at 14:41, Filippo Cucchetto <filippocucchetto at gmail.com>
> wrote:
>
> > I totally agree with the solution proposed by mitch c. With the only
> exception that i would add a DialogButtonGroup qml element into which put
> the buttons. This allows us to add functions and logic without clutturing
> the Dialog component. Furthermore it matches the widget implementation.
>
> My plan was basically that: to have a button box component, so you would
> have two ways to add buttons to the dialog: the StandardButtons enum as
> now, or declare the button box explicitly and put buttons inside.  And
> you’d be able to set buttonBox: null (or something like that) to make it go
> away completely.  In ApplicationWindow you need to declare a toolbar if you
> want one; but in the case of dialogs, the button box has to be
> automatically created (or exist by default) in case you simply set
> standardButtons, because it was introduced with that (oversimplified?) API.
>
> But I didn’t get around to implementing that just yet.
>
> >
> > F.
> >
> > Il 22/ago/2015 13:57, "Curtis Mitch" <mitch.curtis at theqtcompany.com> ha
> scritto:
> >
> >
> > From: development-bounces+mitch.curtis=theqtcompany.com at qt-project.org
> <development-bounces+mitch.curtis=theqtcompany.com at qt-project.org> on
> behalf of Vladimir Moolle <vmoolle at ics.com>
> > Sent: Saturday, 22 August 2015 01:22
> > To: development at qt-project.org
> > Subject: [Development] Qt Quick Controls Dialogs -- enabled state of the
> standard buttons (API choices)
> >
> > [snip]
> >
> > 6. Finally, Dialog could accept (optional) delegates for the buttons
> created, allowing for arbitrary customizations, i.e.:
> > Dialog {
> >     <...>
> >     StandardButtonDelegate {       //name arguably could be better
> >         role: StandardButton.Apply // could be “roles” here even
> >         StandardButton {           // a Button, but with default
> bindings for “text”, etc.
> >             enabled: <some binding expression>
> >         }
> >     }
> >     StandardButtonDelegate {       //name arguably could be better
> >         role: StandardButton.Apply // could be “roles” here even
> >         Rectangle {                // a very custom “button”
> >        <...>
> >             signal clicked         // or a warning emitted by Dialog if
> absent
> >             enabled: <some binding expression>
> >         }
> >     }
> > }
> >
> > [snip]
> >
> > At this stage, wouldn't it just be easier to declare regular buttons as
> children of the dialog and then introduce some Dialog.buttonRole attached
> property? For example:
> >
> > Dialog {
> >     Button {
> >         Dialog.buttonRole: StandardButton.Ok
> >     }
> >     Button {
> >         Dialog.buttonRole: StandardButton.Cancel
> >     }
> > }
> >
> > The dialog can still take care of the layouting of the buttons, and the
> text would even be set for you (unless you want to set your own). We could
> document this as overriding the standardButtons property if both are
> specified for whatever reason.
> >
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150826/00d4b0c0/attachment.html>