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

[Vladimir Moolle]

Hi, a commit was just pushed to
https://codereview.qt-project.org/#/c/138645/ .
The logic follows what was discussed  / suggested in the previous emails in
this thread, with some additions.

Best regards,
Vladimir

On Wed, Aug 26, 2015 at 7:59 PM, Vladimir Moolle <vmoolle at ics.com> wrote:

> 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/20151022/634b025b/attachment.html>