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 <[email protected]> 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 < > [email protected]> wrote: > >> *From:* Vladimir Moolle [mailto:[email protected]] >> *Sent:* Wednesday, 26 August 2015 12:01 AM >> *To:* Rutledge Shawn <[email protected]> >> *Cc:* Filippo Cucchetto <[email protected]>; Curtis Mitch < >> [email protected]>; [email protected] >> *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? >> > >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
