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

[Vlad Stelmahovsky]

I was not talking about QQC1, but about Qt Quick 1
it was QML blamed to be a behemoth, but usually, its  translates to
appropriate C++ code.
My point is even in Qt Quick 1 times performance was not so bad for simple
UIs if using QML wisely

On Fri, Oct 20, 2017 at 10:20 AM, Uwe Rathmann <Uwe.Rathmann at tigertal.de>
wrote:

> 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
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>



-- 
Best regards,
Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20171020/645acad7/attachment.html>