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 <
[email protected]> wrote:
> On 22 Aug 2015, at 14:41, Filippo Cucchetto <[email protected]>
> 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" <[email protected]> ha
> scritto:
> >
> >
> > From: [email protected]
> <[email protected]> on
> behalf of Vladimir Moolle <[email protected]>
> > Sent: Saturday, 22 August 2015 01:22
> > To: [email protected]
> > 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
> > [email protected]
> > http://lists.qt-project.org/mailman/listinfo/development
> >
> > _______________________________________________
> > Development mailing list
> > [email protected]
> > http://lists.qt-project.org/mailman/listinfo/development
>
>
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
