[Interest] Interest Digest Wiki instructions for PI cross compile do not work for PostgreSQL support

[Uwe Rathmann]

On Fri, 20 Oct 2017 09:14:09 +0200, Vlad Stelmahovsky wrote:

> I've created much more complex apps using QtQuick 1 on HW much weaker
> than RPi2 (Symbian phones) w/o such laggin as in this simple calc
> example. Obviously, there something wrong with code and/or system setup

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.

But I never heard anyone complaining about the scene graph !

I would have some critics myself about the C++ part on top, but beside 
its strategy, about when to create the scene graph nodes, it does not 
prevent you from having an efficient application.

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.

Uwe