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
