I must be missing something. I tend to think of eventloops with notify signals are an improvement over polling. You statement seems to say that asking for a value is better, and notifications are to be avoided?
I'm not saying that you should go back to polling. In the case that you have genuine events, for example input or network activity, signals may just be the thing you need. This whole discussion is specifically about properties and their _change_ signals.
Mind that the propagation of dirty flags across a binding graph is a kind of "change signal" in its own right. With QProperty, we just don't calculate the values right away when we notice that a related property has changed. Why is that?
Properties can change fairly often, and synchronously triggering a chain of calculations whenever some property changes can be inefficient and can lead to unexpected intermediate values. This is why we introduce lazy evaluation for property bindings.
With this system, on some level, you indeed have to poll a property to make something happen outside the system. However, certain technologies are inherently based on polling. For example the scene graph rendering a frame every 16ms will poll for changed items every time. For this, a lazy evaluation strategy makes more sense than the usual change signals.
If you want to take advantage of lazy evaluation in such places, you should stop using the change signals there, though. Whenever a property has a change signal, it and everything it depends on needs to be evaluated eagerly.
best, Ulf _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
