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

[Vladimir Moolle]

Hi,

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

Proper componentization -- Dialog does it’s job of handling the content,
accepting and rejecting, etc, and ButtonBox (when parented) brings in logic
responsible for OS-specific standard button layout.  If later there’s a
need to add a “smarter” / differently-behaving ButtonBox alternative, a new
type can be added (and ButtonBox deprecated, potentially) -- without
stumbling into what we have now, with standardButtons API being there
already.

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

Yes, two of them add / layout standard buttons in an OS-specific way (with
the third one being generic), and one of those two should indeed be
eliminated, just as you suggest:

>>> Can’t we just deprecate standardButtons and tell users that ButtonBox
or Dialog.buttonRole is the new way of declaring standard buttons?

With that in mind, and if there are no serious objections, we’d like to
begin implementing a patch tomorrow.

Best regards, Vladimir


On Wed, Aug 26, 2015 at 11:13 AM, Curtis Mitch <
mitch.curtis at theqtcompany.com> wrote:

> *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/6a1dc575/attachment.html>