Kevin Kofler kevin.kofler at chello.at
Thu Aug 22 01:37:21 CEST 2019

André Pönitz wrote:
> Traditionally, "ease of use" and "consistent API" have been a core values
> of Qt, even consciously bought at the cost of some bytes and some cycles.
>
> Of course, this has meant that in certain parts of certain types of
> applications Qt could not sensibly be used. Still, in most cases all, or
> almost all of the code could be "plain Qt", benefiting for creation and
> maintenance from those values. I do believe this was a sensible setup for
> Qt, and I do think there's room for a general purpose framework living
> that compromise also in today's world.
>
> During the last years (ok, let's say, starting around \epsilon A.J. -
> "After Jasmin") this promise has been more or less silently broken, once
> by "leaf" modules deviating, partially intentionally, from previous naming
> conventions, then for real accidents that couldn't be corrected due to
> too-late discovery and compatibility promises, and finally by attempts to
> provide "high performance" alternatives in some places.
>
> In the end we lost uniform, easy-to-use interfaces, and the performance
> gains are only present in very isolated areas of the offering with long
> stretches in-between, hidden by obscure and continuously changing do's and
> don'ts so that they are effectively not visible in real-world GUI-centric
> applications.

The creeping STLization of Qt (deprecating some classes for STL
alternatives, using STL classes in some APIs, etc.) is also part of this
disturbing trend. It typically regresses both ease of use and API
consistency in the name of the holy performance cow.

Kevin Kofler