Re: [Development] Qt Quick Controls Dialogs -- enabled state of the standard buttons (API choices)
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.cur...@theqtcompany.com> wrote:
> *From:* Vladimir Moolle [mailto:vmoo...@ics.com]
> *Sent:* Wednesday, 26 August 2015 12:01 AM
> *To:* Rutledge Shawn
> *Cc:* Filippo Cucchetto ; Curtis Mitch <
> mitch.cur...@theqtcompany.com>; development@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:
>
> }
>
> }
>
>
>
>
>
> 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:
>
>}
>
> }
>
>
>
> 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 rep
Re: [Development] Enginio version and branch names
On Friday, August 21, 2015 12:16:37 AM Stephen Kelly wrote: > Frederik Gladhorn wrote: > > As you know we cannot change the major version as that is not binary > > compatible > > I still see no reason for that to be belived to be true. > > Of course you can fix the major version number and bump the version in the > SONAME. That's the whole point of the version in the SONAME. > > The whole point of different version cadences for Qt modules is to allow > things like that. That's true. But then we didn't actually do a binary incompatible change... Let's not waste more time on this, as we'd like to deprecate the module (see Tuukka's mail) since it doesn't seem to be used enough in the wild to really put effort into it. Cheers, Frederik > > Thanks, > > Steve. > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enginio version and branch names
On Saturday, August 22, 2015 10:47:42 AM Sze Howe Koh wrote: > Hi, > > On 20 August 2015 at 15:31, Frederik Gladhorn > > wrote: > > Hello all, > > > > To make dealing with Enginio a bit easier (I get asked for the right > > version number for each release and keep being confused myself since it > > doesn't see much activity), I will change the future branch names and > > version number. > > > > As you know we cannot change the major version as that is not binary > > compatible, so the major .so version will stay at 1. But we can align the > > rest of the version to Qt release versions. > > > > Branches: > > follow Qt branches: 5.6, 5.6.0, etc > > > > Version numbers: > > follow Qt in minor and patch: 1.6.0 will be released with Qt 5.6.0. > > What do you think of applying this system to the Qt Quick related > modules too? See https://wiki.qt.io/Qt_5_Structure -- the current set > of version numbers is rather chaotic. I personally agree, but there seem many people pulling in many directions, so I'm not sure I'd want to start the bike shed here and now. Cheers, Frederik > > > Regards, > Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Quick Controls Dialogs -- enabled state of the standard buttons (API choices)
From: Vladimir Moolle [mailto:vmoo...@ics.com]
Sent: Wednesday, 26 August 2015 12:01 AM
To: Rutledge Shawn
Cc: Filippo Cucchetto ; Curtis Mitch
; development@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:
}
}
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:
}
}
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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
