Closed j-o closed 9 years ago
I suggest that your deferred implementation is the only one that should exist.
But I havn't tested it yet.
No, sometimes it's very nice to see the outcome of values while changing them, so I think this solution is quite nice, because it gives a choice. However, documentation of this new option is missing. Please add it to the list of options (see "Supported options" in the header documentation) and include a meaningful description of what this option does.
works for me (msvc) - but i'm currently uncomfortable with the idea of favoring lambda exressions over classical signal slot conepts ... because signal slots already provide ways for connecting objects in a non object oriented manner (often lead to bad code and bad oo decisions...) - with lambas as an additional option for slots now, it is even more complicated to understand code and to recap design decisions, control and data flow, communication and architecture ... but for now :ship:
i suggest we discuss (probably not in this PR) a set of design indicators that help to decide which language/oo feature to use with respect to the various kinds/types of communication ...
:shipit:
Please leave a comment after adding commits to a pull request to trigger a notification :)
It set, editors for numbers & plain strings connect to the
editingFinished
signal instead ifvalueChanged
. Useful for long-running calculations depending on properties because withvalueChanged
every key press triggers the changed signal on the property.