22.08.2019, 02:39, "Kevin Kofler" <[email protected]>: > 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.
If you don't need performance, don't use C++. For example, consider Qt for Python. -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
