[Development] QProperty and library coding guide

[Dominik Holland]

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