Uwe, I do wish you luck with QSkinny.
This library lost its way when it started with QML. Hell, even QML lost its way. When the Nokia boys and girls first started talking about this around the Chicago area it wasn't supposed to be an interpreted script kiddie language, but the equivalent of a compiled 4GL. The QML would go through a MOC like compiler generating C++ and Widget code and all features would exist within the C++ Qt framework. That's how it was first pitched to us. Myself and many others were big fans of that idea. It would allow us to quickly prototype the UI and limited functionality for testing on various targets and the only penalty was additional compile time. (You can "throw hardware at it" for faster compile but should never "throw hardware at it" when it comes to the shipping product.)
After that it veered off into the weeds and hooked an 18 bottom plow to a tiny garden tractor.
On 10/20/2017 08:27 AM, interest-requ...@qt-project.org wrote:
A simple push button is made of ( IIRC ) more than 30 QObjects with Quick Controls 1, the version of Quick Controls 2 with less features still consists of 7 QObjects. Each stop of a gradient is made as QObject for no other reason, than to make it accessible from QML. I could continue with almost every control, but let's summarize it this way: Qt/Quick has not been designed to be a lightweight technology. The problems start with the fact that the API of most of those C++ classes are designed to serve the QML use case, making QML mandatory. Finally QML on top does not contribute to performance in any positive way - it is about convenience only. In the best case ( small applications ) you won't notice the startup performance penalties, but you definitely always have to pay with a very significant memory footprint. -- IMHO criticizing having to use QML is very valid and it can't be answered because of having a good performance from the scene graph. And to be clear: it is not QML to blame - it is the fact that you have to use it, when you are in need for a modern graphic stack. And this is exactly why I'm trying to create the QSkinny alternative - one where the decision for the graphic stack is independent from the decision about the programming language you prefer to write your application code with.
-- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog http://lesedi.us/ http://onedollarcontentstore.com
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
