[Development] QProperty and library coding guide

André Pönitz apoenitz at t-online.de
Wed Jul 22 18:55:31 CEST 2020

On Wed, Jul 22, 2020 at 10:27:14AM +0000, Lars Knoll wrote:
> > On 22 Jul 2020, at 11:38, Shawn Rutledge <shawn.rutledge at qt.io> wrote:
> > 
> > 
> >> On 2020 Jul 16, at 11:19, Ulf Hermann <ulf.hermann at qt.io> wrote:
> >> 
> >> Data bindings are a cornerstone of most modern UI frameworks, and Qt is
> >> actually late to the game. If we want Qt to stay relevant, then it needs to
> >> offer the same kind of convenience and performance that other frameworks
> >> offer. This would be an argument for converting all existing properties, and
> >> paying the price, just to make the binding API available.
> > 
> > Has someone done a survey of how bindings are implemented in other frameworks?
> > Maybe there is a cool trick out there that we are missing, which would enable
> > a big leap in efficiency.
> I don’t know of anybody who has done this for C++ yet. I do believe the design
> we have with QProperty is pretty good from an API perspective as well as
> efficient.
> The problem we’re having purely comes from the fact that we’re trying to provide
> BC between versions and are hiding our data behind a d-pointer. If we'd give
> this up the whole problem would go away.

Then the elephant in the room is the question how valuable BC in generally is
for normal Qt users.

How often do we think people are actively taking advantage of Qt's BC promise
(and how often do we hold this promise, and how often is this relevant as
we do not promise to change behaviour while keeping BC)?

For me personally, source compatibility is much more valuable, and BC is a
"good enough" approximaton for that insofar that having to keep BC prevents
a lot of changes that would also break SC. 


More information about the Development mailing list