Am 17.07.20 um 19:12 schrieb Ulf Hermann: >>> I've added a section to this one. Feel free to amend. However, newly >>> designing APIs with QProperty is a different thing than converting old >>> APIs in a compatible way. >> >> The complexity behind the scenes for us to support it is our problem, >> users >> shouldn't care. >> >> They will only care that the code they write is the same, regardless of >> whether it's an old or a new class. > > Indeed the users shouldn't need to care. And they shouldn't use change > signals. Rather, they should use subscribe(), and only if they cannot > express the same thing using a binding. This way we can get rid of the > notified properties in the long run. > > So, new, QProperty-based, properties should not have change signals. > That is something users may notice, and something that needs to be > added to the API design principles.
Mhh, it there are no change signals anymore, i guess i also can't use QObject::connect() anymore and rather use a binding instead ? This is fine, but if two objects are living in different threads how does it work then ? With a Queued connection how it works with signals/slots is pretty clear, but in which thread is the binding evaluated ? With the old properties it's also possible to define a custom behavior for the setter and getter. E.g. for the getter to not emit the changed signal, but just call a worker thread to to this and wait for the feedback to do the actual change and emit the change signal. I guess all this is not possibly anymore with the new QProperty ? If we define that behavior like this can not be done with QProperty but the old way should be used instead everything is fine, but doesn't make the API inconsistent ? As I understood it, we don't want to break SC too much so we will keep all setters/getters in our API. Let's say we create a new type derived from QQuickItem and use a QProperty there, let's name this property "foo". Doesn't it mean we now have a class, which has functions like setWidth and setHeight, but not a function for setFoo ? Sorry if i'm completely missunderstood on how it is supposed to work. Dominik _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
