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

[Roland Hughes]

Don't bastardize QObject or the C++ classes to support a 
never-should-have-existed QML.


The better solution is to purge QML from the package.


On 10/21/2017 02:09 AM, Jean-Michaël Celerier 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.

Wouldn't the better solution here be to allow multiple QML-defined 
objects to coalesce into a single "C++" QObject ? This way you'd get 
much better cache friendliness, less allocations, etc etc.


Ideally this could be doable in C++ too, but with a good meta-object 
refactoring. Something like QObject mixins (this would *really* solve 
world hunger :p). Would certainly require templates at some point.





---
Jean-Michaël Celerier
http://www.jcelerier.name

On Fri, Oct 20, 2017 at 3:38 PM, Roland Hughes 
> wrote:



On 10/20/2017 08:25 AM, Vlad Stelmahovsky wrote:

is someone pushes someone to use QML as a mandatory or store data
into JSON DBs? Where? How? Its ridiculous.



You go out for training to learn how to properly use a tool. All
you are taught is QML and JSON because they are "new." Nothing
ridiculous about it. When the only tool you have is a hammer,
every problem must be a nail.

-- 
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





--
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

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

[Jean-Michaël Celerier]

> 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.

Wouldn't the better solution here be to allow multiple QML-defined objects
to coalesce into a single "C++" QObject ? This way you'd get much better
cache friendliness, less allocations, etc etc.

Ideally this could be doable in C++ too, but with a good meta-object
refactoring. Something like QObject mixins (this would *really* solve world
hunger :p). Would certainly require templates at some point.




---
Jean-Michaël Celerier
http://www.jcelerier.name

On Fri, Oct 20, 2017 at 3:38 PM, Roland Hughes 
wrote:

>
> On 10/20/2017 08:25 AM, Vlad Stelmahovsky wrote:
>
> is someone pushes someone to use QML as a mandatory or store data into
> JSON DBs? Where? How? Its ridiculous.
>
>
> You go out for training to learn how to properly use a tool. All you are
> taught is QML and JSON because they are "new." Nothing ridiculous about it.
> When the only tool you have is a hammer, every problem must be a nail.
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593
> http://www.theminimumyouneedtoknow.comhttp://www.infiniteexposure.nethttp://www.johnsmith-book.comhttp://www.logikalblog.comhttp://www.interestingauthors.com/bloghttp://lesedi.us/http://onedollarcontentstore.com
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

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

[Roland Hughes]

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

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

[Vlad Stelmahovsky]

is someone pushes someone to use QML as a mandatory or store data into JSON
DBs? Where? How? Its ridiculous.

On Fri, Oct 20, 2017 at 3:22 PM, Roland Hughes 
wrote:

>
>
> On 10/20/2017 12:49 AM, Filip Piechocki wrote:
>
>
>
> On Oct 20, 2017 00:11, "Roland Hughes" 
> wrote:
>
> It's not misleading when it is a hog fattened way past market.
>
> 90% of the embedded systems I encounter have no GPU so the driver issue is
> irrelevant. You get rid of all needless things to improve battery life.
> Claiming an i.MX6 which most certainly must need grid power or batteries
> the size of a house is the "normal" embedded processor for medical devices
> or industrial control is simply ludicrous.
>
> And how much of embedded market are devices you are talking about? 5%? 1%?
> 0.1%?
>
> 90% of embedded devices I encounter DO have GPU and these are TVs, set top
> boxes, phones, public transport systems and even fridge. Oh, and using HW
> parts that are specifically designed for some things (like GPUs are for
> graphics) often gives much higher performance/(power draw). Of course it
> depends how much you will use it.
>
> It's the most important segment of the market. Medical devices designed to
> have up to 10 days of continuous use time (not stand by) while on
> batteries. The things deployed to disaster areas
>
> https://www.nbcnews.com/nightly-news/video/almost-80-
> percent-of-puerto-rico-still-without-power-1077278275904
>
> https://www.washingtonpost.com/world/more-than-100-
> feared-buried-as-landslide-destroys-village-in-southwest-
> china/2017/06/23/fbec208e-5881-11e7-9e18-968f6ad1e1d3_
> story.html?utm_term=.c0d01e779851
>
> http://www.cnn.com/2017/10/13/us/california-fires-updates/index.html
>
> http://www.telegraph.co.uk/travel/destinations/caribbean/
> articles/hurricane-irma-hotels-open-island-damage/
>
> If you really are using QML for phone applications thank you for creating
> a generation of wall huggers who can't get more than a few minutes away
> from the nearest power outlet. Your phones are so useful in Puerto Rico
> where many parts only get enough fuel to run the generator for a couple of
> hours each week.
>
> I was using a Pi-II not a 1. The Pi-II has wy more
> horsepower than the vast majority of embedded systems I'm talking about.
>
> But it is still very weak CPU (I don't know the details but llvmpipe
> driver might be limited by single core performance so not much difference
> between RPi 1 and 2) and you are forcing it to draw OpenGL which this CPU
> would like to not handle at all as it is not designed for this.
>
> No, I am not, QML is. Both Qt/Digia and others in here are pushing QML as
> the solution to world hunger. A recent client sent developers to Digia to
> be taught Qt. What did they get taught? QML and JSON files, not a single
> 9*&)(*&)(* mention of widgets or databases or the right way to design a
> system. Guess what happened when they came back from training? They tried
> to develop the entire embedded system using QML and JSON files. A data
> acquisition and control system with many sensors taking readings multiple
> times per second, storing them into a complex directory tree of JSON files.
> Guess what? After a few hours of run time the SD card for data storage went
> write protected because the time it took to rewrite one of the JSON files
> after stuffing a new value into it exceeded the device driver time out so
> the driver put the media into write protection mode to save it.
>
>
> Please do not mislead people. QML is a horrible wretched thing which
> should never have seen the light of day.
>
> If there is no need for it in your specific market - it is ok. In one of a
> companies I worked we had huuuge desktop application done in Qt and I will
> never suggest doing it in QtQuick as widgets are perfect choice for it. But
> there are many solutions where there is need for technology like
> QML/QtQuick, even if it is not perfect (and it is not).
>
> There is no need for QML, ever. In recent releases Digia/Qt has tried to
> manufacture a "need" for it by choosing to implement certain features only
> in the worthless QML.
>
>
> Ok, so maybe you are not misleading people with your blog post - you're
> just showing them that application that is not supposed to be done with
> QtQuick which requires decent HW accelerated OpenGL since December 2012
> (ok, it has changed recently but still hw accelerated graphics is what you
> want) when done in QtQuick and ran on weak CPU and no HW OpenGL then
> performs poorly. Wow. Thanks Captain Obvious!
>
>
> No. I'm showing them that this "solution to world hunger" being pushed by
> the company and crazed eyed frothing at the mouth fanatics is the incorrect
> solution in 99.9% of all situations yet _most_ of them won't
> (*^)(*&)(* bother to consider their platform because _everyone_ talks
> about just how sexy QML is. Just because script kiddies 

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

[Roland Hughes]

On 10/20/2017 12:49 AM, Filip Piechocki wrote:



On Oct 20, 2017 00:11, "Roland Hughes" > wrote:


It's not misleading when it is a hog fattened way past market.

90% of the embedded systems I encounter have no GPU so the driver
issue is irrelevant. You get rid of all needless things to improve
battery life. Claiming an i.MX6 which most certainly must need
grid power or batteries the size of a house is the "normal"
embedded processor for medical devices or industrial control is
simply ludicrous.

And how much of embedded market are devices you are talking about? 5%? 
1%? 0.1%?


90% of embedded devices I encounter DO have GPU and these are TVs, set 
top boxes, phones, public transport systems and even fridge. Oh, and 
using HW parts that are specifically designed for some things (like 
GPUs are for graphics) often gives much higher performance/(power 
draw). Of course it depends how much you will use it.
It's the most important segment of the market. Medical devices designed 
to have up to 10 days of continuous use time (not stand by) while on 
batteries. The things deployed to disaster areas


https://www.nbcnews.com/nightly-news/video/almost-80-percent-of-puerto-rico-still-without-power-1077278275904

https://www.washingtonpost.com/world/more-than-100-feared-buried-as-landslide-destroys-village-in-southwest-china/2017/06/23/fbec208e-5881-11e7-9e18-968f6ad1e1d3_story.html?utm_term=.c0d01e779851

http://www.cnn.com/2017/10/13/us/california-fires-updates/index.html

http://www.telegraph.co.uk/travel/destinations/caribbean/articles/hurricane-irma-hotels-open-island-damage/

If you really are using QML for phone applications thank you for 
creating a generation of wall huggers who can't get more than a few 
minutes away from the nearest power outlet. Your phones are so 
useful in Puerto Rico where many parts only get enough fuel to run the 
generator for a couple of hours each week.



I was using a Pi-II not a 1. The Pi-II has wy
more horsepower than the vast majority of embedded systems I'm
talking about.

But it is still very weak CPU (I don't know the details but llvmpipe 
driver might be limited by single core performance so not much 
difference between RPi 1 and 2) and you are forcing it to draw OpenGL 
which this CPU would like to not handle at all as it is not designed 
for this.
No, I am not, QML is. Both Qt/Digia and others in here are pushing QML 
as the solution to world hunger. A recent client sent developers to 
Digia to be taught Qt. What did they get taught? QML and JSON files, not 
a single 9*&)(*&)(* mention of widgets or databases or the right way 
to design a system. Guess what happened when they came back from 
training? They tried to develop the entire embedded system using QML and 
JSON files. A data acquisition and control system with many sensors 
taking readings multiple times per second, storing them into a complex 
directory tree of JSON files. Guess what? After a few hours of run time 
the SD card for data storage went write protected because the time it 
took to rewrite one of the JSON files after stuffing a new value into it 
exceeded the device driver time out so the driver put the media into 
write protection mode to save it.




Please do not mislead people. QML is a horrible wretched thing
which should never have seen the light of day.

If there is no need for it in your specific market - it is ok. In one 
of a companies I worked we had huuuge desktop application done in Qt 
and I will never suggest doing it in QtQuick as widgets are perfect 
choice for it. But there are many solutions where there is need for 
technology like QML/QtQuick, even if it is not perfect (and it is not).
There is no need for QML, ever. In recent releases Digia/Qt has tried to 
manufacture a "need" for it by choosing to implement certain features 
only in the worthless QML.


Ok, so maybe you are not misleading people with your blog post - 
you're just showing them that application that is not supposed to be 
done with QtQuick which requires decent HW accelerated OpenGL since 
December 2012 (ok, it has changed recently but still hw accelerated 
graphics is what you want) when done in QtQuick and ran on weak CPU 
and no HW OpenGL then performs poorly. Wow. Thanks Captain Obvious!


No. I'm showing them that this "solution to world hunger" being pushed 
by the company and crazed eyed frothing at the mouth fanatics is the 
incorrect solution in 99.9% of all situations yet _most_ of 
them won't (*^)(*&)(* bother to consider their platform because 
_everyone_ talks about just how sexy QML is. Just because script kiddies 
are cheap and just because it is being pushed by the vendor does not 
mean it is a valid or even useful choice. Far too many companies are 
hearing this "solution to world hunger" mantra, starting down the QML 
path because that is all 

Re: [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 
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@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>



-- 
Best regards,
Vlad
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [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

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

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

[Vlad Stelmahovsky]

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

On Fri, Oct 20, 2017 at 7:49 AM, Filip Piechocki 
wrote:

>
>
> On Oct 20, 2017 00:11, "Roland Hughes" 
> wrote:
>
> It's not misleading when it is a hog fattened way past market.
>
> 90% of the embedded systems I encounter have no GPU so the driver issue is
> irrelevant. You get rid of all needless things to improve battery life.
> Claiming an i.MX6 which most certainly must need grid power or batteries
> the size of a house is the "normal" embedded processor for medical devices
> or industrial control is simply ludicrous.
>
> And how much of embedded market are devices you are talking about? 5%? 1%?
> 0.1%?
>
> 90% of embedded devices I encounter DO have GPU and these are TVs, set top
> boxes, phones, public transport systems and even fridge. Oh, and using HW
> parts that are specifically designed for some things (like GPUs are for
> graphics) often gives much higher performance/(power draw). Of course it
> depends how much you will use it.
>
> I was using a Pi-II not a 1. The Pi-II has wy more
> horsepower than the vast majority of embedded systems I'm talking about.
>
> But it is still very weak CPU (I don't know the details but llvmpipe
> driver might be limited by single core performance so not much difference
> between RPi 1 and 2) and you are forcing it to draw OpenGL which this CPU
> would like to not handle at all as it is not designed for this. Already
> shown example of Qt Cinematic Experience which is much more
> sofisticated/fancy than your example app and can run on decent frame rates
> on RPi 1. Like said earlier - do this in widgets or whatever you like
> technology and compare development time (so EFL is out...) and performance
> (so HTML5 is out...).
> Oh, and you are wrong already in a second sentence of your blog post as
> one can think that there is no difference between HTML/JS app and QtQuick
> app. There is. I've run Servo browser engine benchmark limited to 60 items
> on i.MX6 in chromium and got 8fps. Then redo this in QtQuick and got stable
> 60fps. That's 7.5x better. But this discussion makes me think that I need
> to do this in widgets too. Any suggestions how?
>
> Please do not mislead people. QML is a horrible wretched thing which
> should never have seen the light of day.
>
> If there is no need for it in your specific market - it is ok. In one of a
> companies I worked we had huuuge desktop application done in Qt and I will
> never suggest doing it in QtQuick as widgets are perfect choice for it. But
> there are many solutions where there is need for technology like
> QML/QtQuick, even if it is not perfect (and it is not).
>
> Ok, so maybe you are not misleading people with your blog post - you're
> just showing them that application that is not supposed to be done with
> QtQuick which requires decent HW accelerated OpenGL since December 2012
> (ok, it has changed recently but still hw accelerated graphics is what you
> want) when done in QtQuick and ran on weak CPU and no HW OpenGL then
> performs poorly. Wow. Thanks Captain Obvious! You could have asked me and I
> will tell you the result without doing anything. But guess what - it has
> nothing to do with JS engine in this particular example, so your statements
> are wrong.
>
> Offering up "The Microsoft Solution" of "throw hardware and grid power at
> it" is simply no solution for the vast majority of embedded systems
> especially in the medical field.
>
> On 10/19/2017 02:04 PM, Filip Piechocki wrote:
>
> On Thu, Oct 19, 2017 at 2:43 PM, Roland Hughes <
> rol...@logikalsolutions.com> wrote:
>
>> Scroll down and watch the video. QML is an 800 lb gorilla trying to ride
>> in a 2 cylinder car.
>>
>> http://www.logikalsolutions.com/wordpress/information-techno
>> logy/raspberry-qt-part-12-qml-blows-big-stinky-chunks/
>>
>
> Application used here is of course the best candidate for widgets
> implementation as it does not use QtQuick advantages.
>
> Do this:
> https://www.youtube.com/watch?v=wulbR2R1GpM
> in Qt Widgets and share your results.
>
> But please, do not mislead people. You run this app with software OpenGL
> on a device with really weak CPU. Xorg alone eats all resources of RPi 1 as
> it has no HW GPU acceleration.
> In my company we get 20-25 fps when rendering maps on a quite powerful
> (for embedded world) x86 and like 230% CPU usage (of 4 cores) as there is
> no linux driver for its GPU. Meanwhile - we get stable 60fps on i.MX6
> DualLite (2 ARMv7 cores 792MHz) with 12-20% CPU usage. All done with
> QtQuick.
>
>
>> Nasty worthless resource pig which exists only to pursue script kiddies.
>>
>> On 10/19/2017 04:38 AM, Vlad Stelmahovsky wrote:
>>
>> QML is not that resource hogging as JS. dont use JS and you'll be fine
>>
>> On Tue, 

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

[Filip Piechocki]

On Oct 20, 2017 00:11, "Roland Hughes"  wrote:

It's not misleading when it is a hog fattened way past market.

90% of the embedded systems I encounter have no GPU so the driver issue is
irrelevant. You get rid of all needless things to improve battery life.
Claiming an i.MX6 which most certainly must need grid power or batteries
the size of a house is the "normal" embedded processor for medical devices
or industrial control is simply ludicrous.

And how much of embedded market are devices you are talking about? 5%? 1%?
0.1%?

90% of embedded devices I encounter DO have GPU and these are TVs, set top
boxes, phones, public transport systems and even fridge. Oh, and using HW
parts that are specifically designed for some things (like GPUs are for
graphics) often gives much higher performance/(power draw). Of course it
depends how much you will use it.

I was using a Pi-II not a 1. The Pi-II has wy more
horsepower than the vast majority of embedded systems I'm talking about.

But it is still very weak CPU (I don't know the details but llvmpipe driver
might be limited by single core performance so not much difference between
RPi 1 and 2) and you are forcing it to draw OpenGL which this CPU would
like to not handle at all as it is not designed for this. Already shown
example of Qt Cinematic Experience which is much more sofisticated/fancy
than your example app and can run on decent frame rates on RPi 1. Like said
earlier - do this in widgets or whatever you like technology and compare
development time (so EFL is out...) and performance (so HTML5 is out...).
Oh, and you are wrong already in a second sentence of your blog post as one
can think that there is no difference between HTML/JS app and QtQuick app.
There is. I've run Servo browser engine benchmark limited to 60 items on
i.MX6 in chromium and got 8fps. Then redo this in QtQuick and got stable
60fps. That's 7.5x better. But this discussion makes me think that I need
to do this in widgets too. Any suggestions how?

Please do not mislead people. QML is a horrible wretched thing which should
never have seen the light of day.

If there is no need for it in your specific market - it is ok. In one of a
companies I worked we had huuuge desktop application done in Qt and I will
never suggest doing it in QtQuick as widgets are perfect choice for it. But
there are many solutions where there is need for technology like
QML/QtQuick, even if it is not perfect (and it is not).

Ok, so maybe you are not misleading people with your blog post - you're
just showing them that application that is not supposed to be done with
QtQuick which requires decent HW accelerated OpenGL since December 2012
(ok, it has changed recently but still hw accelerated graphics is what you
want) when done in QtQuick and ran on weak CPU and no HW OpenGL then
performs poorly. Wow. Thanks Captain Obvious! You could have asked me and I
will tell you the result without doing anything. But guess what - it has
nothing to do with JS engine in this particular example, so your statements
are wrong.

Offering up "The Microsoft Solution" of "throw hardware and grid power at
it" is simply no solution for the vast majority of embedded systems
especially in the medical field.

On 10/19/2017 02:04 PM, Filip Piechocki wrote:

On Thu, Oct 19, 2017 at 2:43 PM, Roland Hughes 
wrote:

> Scroll down and watch the video. QML is an 800 lb gorilla trying to ride
> in a 2 cylinder car.
>
> http://www.logikalsolutions.com/wordpress/information-techno
> logy/raspberry-qt-part-12-qml-blows-big-stinky-chunks/
>

Application used here is of course the best candidate for widgets
implementation as it does not use QtQuick advantages.

Do this:
https://www.youtube.com/watch?v=wulbR2R1GpM
in Qt Widgets and share your results.

But please, do not mislead people. You run this app with software OpenGL on
a device with really weak CPU. Xorg alone eats all resources of RPi 1 as it
has no HW GPU acceleration.
In my company we get 20-25 fps when rendering maps on a quite powerful (for
embedded world) x86 and like 230% CPU usage (of 4 cores) as there is no
linux driver for its GPU. Meanwhile - we get stable 60fps on i.MX6 DualLite
(2 ARMv7 cores 792MHz) with 12-20% CPU usage. All done with QtQuick.


> Nasty worthless resource pig which exists only to pursue script kiddies.
>
> On 10/19/2017 04:38 AM, Vlad Stelmahovsky wrote:
>
> QML is not that resource hogging as JS. dont use JS and you'll be fine
>
> On Tue, Oct 17, 2017 at 8:11 PM, Roland Hughes <
> rol...@logikalsolutions.com> wrote:
>
>>
>>
>> On 10/17/2017 12:54 PM, interest-requ...@qt-project.org wrote:
>>
>> On ter?a-feira, 17 de outubro de 2017 08:11:13 PDT Roland Hughes wrote:
>>
>> The bug tracking system is under our control - it will not just
>> disappear (from our perspective).
>>
>> Oh yes it will!
>>
>> Speaking as someone who has heard that soo many times before, let's
>> just count a few 

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

[Sze Howe Koh]

On 19 October 2017 at 20:43, Roland Hughes  wrote:
>
> Scroll down and watch the video. QML is an 800 lb gorilla trying to ride in a 
> 2 cylinder car.
>
> http://www.logikalsolutions.com/wordpress/information-technology/raspberry-qt-part-12-qml-blows-big-stinky-chunks/


Roland,

Your code uses Qt Quick Controls 1, which was not designed with
embedded systems In mind.

Try again with Qt Quick Controls 2, which was designed for embedded
applications. You will see a marked improvement in performance and
resource consumption.


Regards,
Sze-Howe
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

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

[Roland Hughes]

It's not misleading when it is a hog fattened way past market.

90% of the embedded systems I encounter have no GPU so the driver issue 
is irrelevant. You get rid of all needless things to improve battery 
life. Claiming an i.MX6 which most certainly must need grid power or 
batteries the size of a house is the "normal" embedded processor for 
medical devices or industrial control is simply ludicrous.


I was using a Pi-II not a 1. The Pi-II has wy more 
horsepower than the vast majority of embedded systems I'm talking about.


Please do not mislead people. QML is a horrible wretched thing which 
should never have seen the light of day. Offering up "The Microsoft 
Solution" of "throw hardware and grid power at it" is simply no solution 
for the vast majority of embedded systems especially in the medical field.



On 10/19/2017 02:04 PM, Filip Piechocki wrote:
On Thu, Oct 19, 2017 at 2:43 PM, Roland Hughes 
> wrote:


Scroll down and watch the video. QML is an 800 lb gorilla trying
to ride in a 2 cylinder car.


http://www.logikalsolutions.com/wordpress/information-technology/raspberry-qt-part-12-qml-blows-big-stinky-chunks/




Application used here is of course the best candidate for widgets 
implementation as it does not use QtQuick advantages.


Do this:
https://www.youtube.com/watch?v=wulbR2R1GpM
in Qt Widgets and share your results.

But please, do not mislead people. You run this app with software 
OpenGL on a device with really weak CPU. Xorg alone eats all resources 
of RPi 1 as it has no HW GPU acceleration.
In my company we get 20-25 fps when rendering maps on a quite powerful 
(for embedded world) x86 and like 230% CPU usage (of 4 cores) as there 
is no linux driver for its GPU. Meanwhile - we get stable 60fps on 
i.MX6 DualLite (2 ARMv7 cores 792MHz) with 12-20% CPU usage. All done 
with QtQuick.


Nasty worthless resource pig which exists only to pursue script
kiddies.


On 10/19/2017 04:38 AM, Vlad Stelmahovsky wrote:

QML is not that resource hogging as JS. dont use JS and you'll be
fine

On Tue, Oct 17, 2017 at 8:11 PM, Roland Hughes
> wrote:



On 10/17/2017 12:54 PM, interest-requ...@qt-project.org
 wrote:

On ter?a-feira, 17 de outubro de 2017 08:11:13 PDT Roland
Hughes wrote:

The bug tracking system is under our control - it will not just
disappear (from our perspective).

Oh yes it will!

Speaking as someone who has heard that soo many times before, let's
just count a few for Qt shall we.

The Trolltech bug database was never going to just disappear (from our
perspective). It did. A tiny fraction of the bugs migrated to the new
system but most were mass exterminated with

The TT TT was not a public database. It existed internally only. When we
switched to a public bugtracker, we could only export some entries 
since many
had confidential customer information. Those that were exported had to 
be
review by a person to make sure we were not violation any NDAs or
confidentiality.

That's the same reason why the code repository starts with Qt 4.5, not 
earlier
versions.


"The version this bug is reported against is no longer supported..."

The Nokia bug tracker was never going to just disappear (from our
perspective). It did. Few, if any of the older bugs made it into the
current database. Most were mass exterminated with

There was no Nokia database. We switched straight from the internal tdb
(that's what it was called) to JIRA.

There was a Nokia bug base as well, at least for a while. I
and others entered bugs into it back in the day. Your
argument also re-enforces a great many bugs "simply disappeared."

I hear from quite a few companies in similar boats. They started
development for a medical/industrial device which had a lengthy
testing/approval process, filed bug reports for that version only to see
them rot or fall victim to a mass extermination.

Most open source projects don't support old versions, since they don't 
have
the manpower to do so.


The current owners of Qt and the current OpenSource maintainers don't
offer or seem to understand the concept of an LTS (Long Term Support)
version. They are constantly pursuing script kiddies and that worthless
QML instead of maintaining the base which built them. This will soon
force a fork in the OpenSource project. One which rips out all of the
QML and focuses on 

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

[Filip Piechocki]

On Thu, Oct 19, 2017 at 2:43 PM, Roland Hughes 
wrote:

> Scroll down and watch the video. QML is an 800 lb gorilla trying to ride
> in a 2 cylinder car.
>
> http://www.logikalsolutions.com/wordpress/information-
> technology/raspberry-qt-part-12-qml-blows-big-stinky-chunks/
>

Application used here is of course the best candidate for widgets
implementation as it does not use QtQuick advantages.

Do this:
https://www.youtube.com/watch?v=wulbR2R1GpM
in Qt Widgets and share your results.

But please, do not mislead people. You run this app with software OpenGL on
a device with really weak CPU. Xorg alone eats all resources of RPi 1 as it
has no HW GPU acceleration.
In my company we get 20-25 fps when rendering maps on a quite powerful (for
embedded world) x86 and like 230% CPU usage (of 4 cores) as there is no
linux driver for its GPU. Meanwhile - we get stable 60fps on i.MX6 DualLite
(2 ARMv7 cores 792MHz) with 12-20% CPU usage. All done with QtQuick.


> Nasty worthless resource pig which exists only to pursue script kiddies.
>
> On 10/19/2017 04:38 AM, Vlad Stelmahovsky wrote:
>
> QML is not that resource hogging as JS. dont use JS and you'll be fine
>
> On Tue, Oct 17, 2017 at 8:11 PM, Roland Hughes <
> rol...@logikalsolutions.com> wrote:
>
>>
>>
>> On 10/17/2017 12:54 PM, interest-requ...@qt-project.org wrote:
>>
>> On ter?a-feira, 17 de outubro de 2017 08:11:13 PDT Roland Hughes wrote:
>>
>> The bug tracking system is under our control - it will not just
>> disappear (from our perspective).
>>
>> Oh yes it will!
>>
>> Speaking as someone who has heard that soo many times before, let's
>> just count a few for Qt shall we.
>>
>> The Trolltech bug database was never going to just disappear (from our
>> perspective). It did. A tiny fraction of the bugs migrated to the new
>> system but most were mass exterminated with
>>
>> The TT TT was not a public database. It existed internally only. When we
>> switched to a public bugtracker, we could only export some entries since many
>> had confidential customer information. Those that were exported had to be
>> review by a person to make sure we were not violation any NDAs or
>> confidentiality.
>>
>> That's the same reason why the code repository starts with Qt 4.5, not 
>> earlier
>> versions.
>>
>>
>> "The version this bug is reported against is no longer supported..."
>>
>> The Nokia bug tracker was never going to just disappear (from our
>> perspective). It did. Few, if any of the older bugs made it into the
>> current database. Most were mass exterminated with
>>
>> There was no Nokia database. We switched straight from the internal tdb
>> (that's what it was called) to JIRA.
>>
>> There was a Nokia bug base as well, at least for a while. I and others
>> entered bugs into it back in the day. Your argument also re-enforces a
>> great many bugs "simply disappeared."
>>
>> I hear from quite a few companies in similar boats. They started
>> development for a medical/industrial device which had a lengthy
>> testing/approval process, filed bug reports for that version only to see
>> them rot or fall victim to a mass extermination.
>>
>> Most open source projects don't support old versions, since they don't have
>> the manpower to do so.
>>
>>
>> The current owners of Qt and the current OpenSource maintainers don't
>> offer or seem to understand the concept of an LTS (Long Term Support)
>> version. They are constantly pursuing script kiddies and that worthless
>> QML instead of maintaining the base which built them. This will soon
>> force a fork in the OpenSource project. One which rips out all of the
>> QML and focuses on nothing but bug fixes for 12 years. Yes, 12 years.
>>
>> Again, offence taken.
>>
>> Take all of the offense you want. Medical devices and industrial controls
>> need LTS versions, not resource hogging QML features. Qt's chasing of the
>> idiot phone market which has 6 months at best life spans is alienating and
>> chasing away the very industries which made Qt successful.
>>
>> I don't know who plans on forking. There's no such division in the community,
>> so any attempt to do so will probably start with very few developers. Almost
>> certainly, fewer than critical mass to maintain the codebase.
>>
>> See TQt (Trinity Project) for an example of a fork attempt.
>>
>> It's easy to fork something you have been maintaining internally for
>> years. There _IS_ such a division. You don't know about it because they
>> don't come here. They justifiably believe they've been abandoned. The
>> relentless pursuit of "new cool features" to please the phone crowd is
>> causing the much larger medical device and industrial control industries to
>> create their own LTS.
>>
>> How many questions have you seen on here over the past 18 months about Qt
>> 3? That project Harmman (sp?) calls about periodically sells north of a
>> million units per year and the company is maintaining Qt 3 on its own so
>> they can make minor product 

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

[Roland Hughes]

Because I'm the one who gets called in to sweep up the train wreck. I 
work in the medical and industrial device world where QML is __NEVER__ a 
good choice, let alone a correct choice, but, script kiddies are cheap. 
When you are called in to sweep it up, the client never wants to hear 
they have to throw out 90% of a project which is already late and not 
meeting any of the design targets, they just want a "quick fix" which 
doesn't exist.


It's amazing really. I see the same project moving from pimp to pimp to 
pimp for north of 6 months and most of them end up calling me so I don't 
even have to see the project moving. Had they thrown everything out and 
started with a pure C++/Qt widget solution they would already have been 
done. Still, they keep searching for a "quick fix."



On 10/19/2017 08:51 AM, Sérgio Martins wrote:

On Thu, Oct 19, 2017 at 1:43 PM, Roland Hughes
 wrote:

Scroll down and watch the video. QML is an 800 lb gorilla trying to ride in
a 2 cylinder car.

http://www.logikalsolutions.com/wordpress/information-technology/raspberry-qt-part-12-qml-blows-big-stinky-chunks/

Nasty worthless resource pig which exists only to pursue script kiddies.

Hi Roland,

If you don't like QML why are you obsessed with it ? Spending all this
energy writing blogs and recording videos.

I don't like Electron, so what I do is ignore it exists and not go on
their mailing lists offending their software.


Regards,
Sérgio M.


--
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

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

[Uwe Rathmann]

On Thu, 19 Oct 2017 08:06:26 -0500, Roland Hughes wrote:

> 1) It's QML ...

In case you prefer using the Qt/Quick graphic stack without QML you might 
be interested in what I'm working on: https://github.com/uwerat/qskinny.

In fact the heaviness of Qt/Quick is not only QML related and I had/have 
to reimplement almost everything of the Qt/Quick C++ layer - beside of 
the scene graph and QQuickItem/QQuickWindow.

The project is far from being complete, documentation has not been done 
and the quality of the examples is pretty poor. But I hope I will have 
something in a few months, that is good enough to show its potential and 
I can decide if there is enough interest to continue.

Uwe

PS: the project is driven by a commercial application and on github you 
can see only the subset I'm allowed to release. We have reached an 
initial version ( about ~50 different pages full of content ) and the 
startup time feels like 'ls' in the terminal. ( the previous generation 
of the product - less pages, but with QML - needs seconds ).



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

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

[Sérgio Martins]

On Thu, Oct 19, 2017 at 1:43 PM, Roland Hughes
 wrote:
> Scroll down and watch the video. QML is an 800 lb gorilla trying to ride in
> a 2 cylinder car.
>
> http://www.logikalsolutions.com/wordpress/information-technology/raspberry-qt-part-12-qml-blows-big-stinky-chunks/
>
> Nasty worthless resource pig which exists only to pursue script kiddies.

Hi Roland,

If you don't like QML why are you obsessed with it ? Spending all this
energy writing blogs and recording videos.

I don't like Electron, so what I do is ignore it exists and not go on
their mailing lists offending their software.


Regards,
Sérgio M.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

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

[Konstantin Tokarev]

19.10.2017, 16:11, "Roland Hughes" <rol...@logikalsolutions.com>:
> Laszlo,
>
> 1) It's QML. Massive stinky pig which is __ALWAYS__ the wrong choice for any 
> project.

I'd like to point out that whining is __ALWAYS__ a wrong approach for 
communications on
technical mailing list.

>
> 2) EGLFS is how we got here. The Wiki instructions are pure excrement for 
> anything more complex than "Hello World."
>
> But that's fine because the bug report for the Wiki instructions has been 
> "Resolved" without any action taken. It sits out there spawning countless 
> other Wiki and blog posts all based on broken instructions.
>
> https://www.youtube.com/watch?v=MAfCQ-t7xY0
>
> On 10/19/2017 07:57 AM, Laszlo Agocs wrote:
>> Perhaps because it could be running with a pure software OpenGL 
>> implementation (Mesa llvmpipe) which Raspbian and friends tend to use to 
>> provide OpenGL on X11. (at least until VC4 becomes the default; in the 
>> meantime acceleration is limited to when running directly on Dispmanx, hence 
>> our general recommendation of using eglfs on embedded boards in order to cut 
>> out the potentially problematic middle layers)
>>
>> If that’s the case, then the performance issues showcased here have nothing 
>> to with QML, Qt Quick or anything Qt really. Run with QSG_INFO=1 to verify.
>>
>> Cheers,
>>
>> Laszlo
>>
>> From: Interest [mailto:interest-bounces+laszlo.agocs=qt...@qt-project.org] 
>> On Behalf Of Roland Hughes
>> Sent: torsdag 19. oktober 2017 14.43
>> To: Vlad Stelmahovsky <vladstelmahov...@gmail.com>
>> Cc: interest <interest@qt-project.org>
>> Subject: Re: [Interest] Interest Digest Wiki instructions for PI cross 
>> compile do not work for PostgreSQL support
>>
>> Scroll down and watch the video. QML is an 800 lb gorilla trying to ride in 
>> a 2 cylinder car.
>>
>> http://www.logikalsolutions.com/wordpress/information-technology/raspberry-qt-part-12-qml-blows-big-stinky-chunks/
>>
>> Nasty worthless resource pig which exists only to pursue script kiddies.
>>
>> On 10/19/2017 04:38 AM, Vlad Stelmahovsky wrote:
>>> QML is not that resource hogging as JS. dont use JS and you'll be fine
>>>
>>> On Tue, Oct 17, 2017 at 8:11 PM, Roland Hughes 
>>> <rol...@logikalsolutions.com> wrote:
>>>> On 10/17/2017 12:54 PM, interest-requ...@qt-project.org wrote:
>>>>> On ter?a-feira, 17 de outubro de 2017 08:11:13 PDT Roland Hughes wrote:
>>>>>>> The bug tracking system is under our control - it will not just
>>>>>>>
>>>>>>> disappear (from our perspective).
>>>>>>
>>>>>> Oh yes it will!
>>>>>>
>>>>>> Speaking as someone who has heard that soo many times before, let's
>>>>>>
>>>>>> just count a few for Qt shall we.
>>>>>>
>>>>>> The Trolltech bug database was never going to just disappear (from our
>>>>>>
>>>>>> perspective). It did. A tiny fraction of the bugs migrated to the new
>>>>>>
>>>>>> system but most were mass exterminated with
>>>>>
>>>>> The TT TT was not a public database. It existed internally only. When we
>>>>>
>>>>> switched to a public bugtracker, we could only export some entries since 
>>>>> many
>>>>>
>>>>> had confidential customer information. Those that were exported had to be
>>>>>
>>>>> review by a person to make sure we were not violation any NDAs or
>>>>>
>>>>> confidentiality.
>>>>>
>>>>> That's the same reason why the code repository starts with Qt 4.5, not 
>>>>> earlier
>>>>>
>>>>> versions.
>>>>>> "The version this bug is reported against is no longer supported..."
>>>>>>
>>>>>> The Nokia bug tracker was never going to just disappear (from our
>>>>>>
>>>>>> perspective). It did. Few, if any of the older bugs made it into the
>>>>>>
>>>>>> current database. Most were mass exterminated with
>>>>>
>>>>> There was no Nokia database. We switched straight from the internal tdb
>>>>>
>>>>> (that's what it was called) to JIRA.
>>>>
>>>> There was a Nokia bug base as well, at least for a while. I and oth

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

[Roland Hughes]

Laszlo,

1) It's QML. Massive stinky pig which is __ALWAYS__ the wrong choice for 
any project.


2) EGLFS is how we got here. The Wiki instructions are pure excrement 
for anything more complex than "Hello World."


But that's fine because the bug report for the Wiki instructions has 
been "Resolved" without any action taken. It sits out there spawning 
countless other Wiki and blog posts all based on broken instructions.


https://www.youtube.com/watch?v=MAfCQ-t7xY0



On 10/19/2017 07:57 AM, Laszlo Agocs wrote:


Perhaps because it could be running with a pure software OpenGL 
implementation (Mesa llvmpipe) which Raspbian and friends tend to use 
to provide OpenGL on X11. (at least until VC4 becomes the default; in 
the meantime acceleration is limited to when running directly on 
Dispmanx, hence our general recommendation of using eglfs on embedded 
boards in order to cut out the potentially problematic middle layers)


If that’s the case, then the performance issues showcased here have 
nothing to with QML, Qt Quick or anything Qt really. Run with 
QSG_INFO=1 to verify.


Cheers,

Laszlo

*From:*Interest 
[mailto:interest-bounces+laszlo.agocs=qt...@qt-project.org] *On Behalf 
Of *Roland Hughes

*Sent:* torsdag 19. oktober 2017 14.43
*To:* Vlad Stelmahovsky <vladstelmahov...@gmail.com>
*Cc:* interest <interest@qt-project.org>
*Subject:* Re: [Interest] Interest Digest Wiki instructions for PI 
cross compile do not work for PostgreSQL support


Scroll down and watch the video. QML is an 800 lb gorilla trying to 
ride in a 2 cylinder car.


http://www.logikalsolutions.com/wordpress/information-technology/raspberry-qt-part-12-qml-blows-big-stinky-chunks/

Nasty worthless resource pig which exists only to pursue script kiddies.

On 10/19/2017 04:38 AM, Vlad Stelmahovsky wrote:

QML is not that resource hogging as JS. dont use JS and you'll be fine

On Tue, Oct 17, 2017 at 8:11 PM, Roland Hughes
<rol...@logikalsolutions.com <mailto:rol...@logikalsolutions.com>>
wrote:

On 10/17/2017 12:54 PM, interest-requ...@qt-project.org
<mailto:interest-requ...@qt-project.org> wrote:

On ter?a-feira, 17 de outubro de 2017 08:11:13 PDT Roland Hughes 
wrote:

The bug tracking system is under our control - it will not 
just

disappear (from our perspective).

Oh yes it will!

Speaking as someone who has heard that soo many times 
before, let's

just count a few for Qt shall we.

The Trolltech bug database was never going to just disappear 
(from our

perspective). It did. A tiny fraction of the bugs migrated to 
the new

system but most were mass exterminated with

The TT TT was not a public database. It existed internally only. 
When we

switched to a public bugtracker, we could only export some entries 
since many

had confidential customer information. Those that were exported had 
to be

review by a person to make sure we were not violation any NDAs or

confidentiality.

That's the same reason why the code repository starts with Qt 4.5, 
not earlier

versions.

"The version this bug is reported against is no longer 
supported..."

The Nokia bug tracker was never going to just disappear (from 
our

perspective). It did. Few, if any of the older bugs made it 
into the

current database. Most were mass exterminated with

There was no Nokia database. We switched straight from the internal 
tdb

(that's what it was called) to JIRA.

There was a Nokia bug base as well, at least for a while. I
and others entered bugs into it back in the day. Your argument
also re-enforces a great many bugs "simply disappeared."

I hear from quite a few companies in similar boats. They started

development for a medical/industrial device which had a lengthy

testing/approval process, filed bug reports for that version 
only to see

them rot or fall victim to a mass extermination.

Most open source projects don't support old versions, since they 
don't have

the manpower to do so.

The current owners of Qt and the current OpenSource maintainers 
don't

offer or seem to understand the concept of an LTS (Long Term 
Support)

version. They are constantly pursuing script kiddies and that 
worthless

QML instead of maintaining the base which built them. This will 
soon

force a fork in the OpenSource project. One which rips out all 
of the

QML and focuses on nothing but bug fixes for 12 years. Yes, 12 
years.

Ag

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

[Laszlo Agocs]

Perhaps because it could be running with a pure software OpenGL implementation 
(Mesa llvmpipe) which Raspbian and friends tend to use to provide OpenGL on 
X11. (at least until VC4 becomes the default; in the meantime acceleration is 
limited to when running directly on Dispmanx, hence our general recommendation 
of using eglfs on embedded boards in order to cut out the potentially 
problematic middle layers)

If that’s the case, then the performance issues showcased here have nothing to 
with QML, Qt Quick or anything Qt really. Run with QSG_INFO=1 to verify.

Cheers,
Laszlo

From: Interest [mailto:interest-bounces+laszlo.agocs=qt...@qt-project.org] On 
Behalf Of Roland Hughes
Sent: torsdag 19. oktober 2017 14.43
To: Vlad Stelmahovsky <vladstelmahov...@gmail.com>
Cc: interest <interest@qt-project.org>
Subject: Re: [Interest] Interest Digest Wiki instructions for PI cross compile 
do not work for PostgreSQL support


Scroll down and watch the video. QML is an 800 lb gorilla trying to ride in a 2 
cylinder car.

http://www.logikalsolutions.com/wordpress/information-technology/raspberry-qt-part-12-qml-blows-big-stinky-chunks/

Nasty worthless resource pig which exists only to pursue script kiddies.

On 10/19/2017 04:38 AM, Vlad Stelmahovsky wrote:
QML is not that resource hogging as JS. dont use JS and you'll be fine

On Tue, Oct 17, 2017 at 8:11 PM, Roland Hughes 
<rol...@logikalsolutions.com<mailto:rol...@logikalsolutions.com>> wrote:



On 10/17/2017 12:54 PM, 
interest-requ...@qt-project.org<mailto:interest-requ...@qt-project.org> wrote:

On ter?a-feira, 17 de outubro de 2017 08:11:13 PDT Roland Hughes wrote:

The bug tracking system is under our control - it will not just

disappear (from our perspective).

Oh yes it will!



Speaking as someone who has heard that soo many times before, let's

just count a few for Qt shall we.



The Trolltech bug database was never going to just disappear (from our

perspective). It did. A tiny fraction of the bugs migrated to the new

system but most were mass exterminated with

The TT TT was not a public database. It existed internally only. When we

switched to a public bugtracker, we could only export some entries since many

had confidential customer information. Those that were exported had to be

review by a person to make sure we were not violation any NDAs or

confidentiality.



That's the same reason why the code repository starts with Qt 4.5, not earlier

versions.



"The version this bug is reported against is no longer supported..."



The Nokia bug tracker was never going to just disappear (from our

perspective). It did. Few, if any of the older bugs made it into the

current database. Most were mass exterminated with

There was no Nokia database. We switched straight from the internal tdb

(that's what it was called) to JIRA.
There was a Nokia bug base as well, at least for a while. I and others entered 
bugs into it back in the day. Your argument also re-enforces a great many bugs 
"simply disappeared."


I hear from quite a few companies in similar boats. They started

development for a medical/industrial device which had a lengthy

testing/approval process, filed bug reports for that version only to see

them rot or fall victim to a mass extermination.

Most open source projects don't support old versions, since they don't have

the manpower to do so.



The current owners of Qt and the current OpenSource maintainers don't

offer or seem to understand the concept of an LTS (Long Term Support)

version. They are constantly pursuing script kiddies and that worthless

QML instead of maintaining the base which built them. This will soon

force a fork in the OpenSource project. One which rips out all of the

QML and focuses on nothing but bug fixes for 12 years. Yes, 12 years.

Again, offence taken.
Take all of the offense you want. Medical devices and industrial controls need 
LTS versions, not resource hogging QML features. Qt's chasing of the idiot 
phone market which has 6 months at best life spans is alienating and chasing 
away the very industries which made Qt successful.


I don't know who plans on forking. There's no such division in the community,

so any attempt to do so will probably start with very few developers. Almost

certainly, fewer than critical mass to maintain the codebase.



See TQt (Trinity Project) for an example of a fork attempt.
It's easy to fork something you have been maintaining internally for years. 
There _IS_ such a division. You don't know about it because they don't come 
here. They justifiably believe they've been abandoned. The relentless pursuit 
of "new cool features" to please the phone crowd is causing the much larger 
medical device and industrial control industries to create their own LTS.

How many questions have you seen on here over the past 18 months about Qt 3? 
That project Harmman (sp?) calls about periodically sells north of a millio

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

[Roland Hughes]

Scroll down and watch the video. QML is an 800 lb gorilla trying to ride 
in a 2 cylinder car.


http://www.logikalsolutions.com/wordpress/information-technology/raspberry-qt-part-12-qml-blows-big-stinky-chunks/

Nasty worthless resource pig which exists only to pursue script kiddies.


On 10/19/2017 04:38 AM, Vlad Stelmahovsky wrote:

QML is not that resource hogging as JS. dont use JS and you'll be fine

On Tue, Oct 17, 2017 at 8:11 PM, Roland Hughes 
> wrote:




On 10/17/2017 12:54 PM, interest-requ...@qt-project.org
 wrote:

On ter?a-feira, 17 de outubro de 2017 08:11:13 PDT Roland Hughes
wrote:

The bug tracking system is under our control - it will not just
disappear (from our perspective).

Oh yes it will!

Speaking as someone who has heard that soo many times before, let's
just count a few for Qt shall we.

The Trolltech bug database was never going to just disappear (from our
perspective). It did. A tiny fraction of the bugs migrated to the new
system but most were mass exterminated with

The TT TT was not a public database. It existed internally only. When we
switched to a public bugtracker, we could only export some entries since 
many
had confidential customer information. Those that were exported had to be
review by a person to make sure we were not violation any NDAs or
confidentiality.

That's the same reason why the code repository starts with Qt 4.5, not 
earlier
versions.


"The version this bug is reported against is no longer supported..."

The Nokia bug tracker was never going to just disappear (from our
perspective). It did. Few, if any of the older bugs made it into the
current database. Most were mass exterminated with

There was no Nokia database. We switched straight from the internal tdb
(that's what it was called) to JIRA.

There was a Nokia bug base as well, at least for a while. I and
others entered bugs into it back in the day. Your argument also
re-enforces a great many bugs "simply disappeared."

I hear from quite a few companies in similar boats. They started
development for a medical/industrial device which had a lengthy
testing/approval process, filed bug reports for that version only to see
them rot or fall victim to a mass extermination.

Most open source projects don't support old versions, since they don't have
the manpower to do so.


The current owners of Qt and the current OpenSource maintainers don't
offer or seem to understand the concept of an LTS (Long Term Support)
version. They are constantly pursuing script kiddies and that worthless
QML instead of maintaining the base which built them. This will soon
force a fork in the OpenSource project. One which rips out all of the
QML and focuses on nothing but bug fixes for 12 years. Yes, 12 years.

Again, offence taken.

Take all of the offense you want. Medical devices and industrial
controls need LTS versions, not resource hogging QML features.
Qt's chasing of the idiot phone market which has 6 months at best
life spans is alienating and chasing away the very industries
which made Qt successful.

I don't know who plans on forking. There's no such division in the 
community,
so any attempt to do so will probably start with very few developers. Almost
certainly, fewer than critical mass to maintain the codebase.

See TQt (Trinity Project) for an example of a fork attempt.

It's easy to fork something you have been maintaining internally
for years. There _IS_ such a division. You don't know about it
because they don't come here. They justifiably believe they've
been abandoned. The relentless pursuit of "new cool features" to
please the phone crowd is causing the much larger medical device
and industrial control industries to create their own LTS.

How many questions have you seen on here over the past 18 months
about Qt 3? That project Harmman (sp?) calls about periodically
sells north of a million units per year and the company is
maintaining Qt 3 on its own so they can make minor product
enhancements which don't have to go though multi-year clinical
trials. They aren't the only calls I get about products using Qt
3, 4.2, and the most likely soon to be orphaned (if not already)
4.8. Every company I am contacted about using earlier versions has
their own staff maintaining the code base today. They have had no
other choice. If anything, joining forces with someone who is not
a competitor but using the same tool set will lighten their load.

-- 
Roland Hughes, President

Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com

http://www.infiniteexposure.net 

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

[Vlad Stelmahovsky]

QML is not that resource hogging as JS. dont use JS and you'll be fine

On Tue, Oct 17, 2017 at 8:11 PM, Roland Hughes 
wrote:

>
>
> On 10/17/2017 12:54 PM, interest-requ...@qt-project.org wrote:
>
> On ter?a-feira, 17 de outubro de 2017 08:11:13 PDT Roland Hughes wrote:
>
> The bug tracking system is under our control - it will not just
> disappear (from our perspective).
>
> Oh yes it will!
>
> Speaking as someone who has heard that soo many times before, let's
> just count a few for Qt shall we.
>
> The Trolltech bug database was never going to just disappear (from our
> perspective). It did. A tiny fraction of the bugs migrated to the new
> system but most were mass exterminated with
>
> The TT TT was not a public database. It existed internally only. When we
> switched to a public bugtracker, we could only export some entries since many
> had confidential customer information. Those that were exported had to be
> review by a person to make sure we were not violation any NDAs or
> confidentiality.
>
> That's the same reason why the code repository starts with Qt 4.5, not earlier
> versions.
>
>
> "The version this bug is reported against is no longer supported..."
>
> The Nokia bug tracker was never going to just disappear (from our
> perspective). It did. Few, if any of the older bugs made it into the
> current database. Most were mass exterminated with
>
> There was no Nokia database. We switched straight from the internal tdb
> (that's what it was called) to JIRA.
>
> There was a Nokia bug base as well, at least for a while. I and others
> entered bugs into it back in the day. Your argument also re-enforces a
> great many bugs "simply disappeared."
>
>  I hear from quite a few companies in similar boats. They started
> development for a medical/industrial device which had a lengthy
> testing/approval process, filed bug reports for that version only to see
> them rot or fall victim to a mass extermination.
>
> Most open source projects don't support old versions, since they don't have
> the manpower to do so.
>
>
> The current owners of Qt and the current OpenSource maintainers don't
> offer or seem to understand the concept of an LTS (Long Term Support)
> version. They are constantly pursuing script kiddies and that worthless
> QML instead of maintaining the base which built them. This will soon
> force a fork in the OpenSource project. One which rips out all of the
> QML and focuses on nothing but bug fixes for 12 years. Yes, 12 years.
>
> Again, offence taken.
>
> Take all of the offense you want. Medical devices and industrial controls
> need LTS versions, not resource hogging QML features. Qt's chasing of the
> idiot phone market which has 6 months at best life spans is alienating and
> chasing away the very industries which made Qt successful.
>
>
> I don't know who plans on forking. There's no such division in the community,
> so any attempt to do so will probably start with very few developers. Almost
> certainly, fewer than critical mass to maintain the codebase.
>
> See TQt (Trinity Project) for an example of a fork attempt.
>
> It's easy to fork something you have been maintaining internally for
> years. There _IS_ such a division. You don't know about it because they
> don't come here. They justifiably believe they've been abandoned. The
> relentless pursuit of "new cool features" to please the phone crowd is
> causing the much larger medical device and industrial control industries to
> create their own LTS.
>
> How many questions have you seen on here over the past 18 months about Qt
> 3? That project Harmman (sp?) calls about periodically sells north of a
> million units per year and the company is maintaining Qt 3 on its own so
> they can make minor product enhancements which don't have to go though
> multi-year clinical trials. They aren't the only calls I get about products
> using Qt 3, 4.2, and the most likely soon to be orphaned (if not already)
> 4.8. Every company I am contacted about using earlier versions has their
> own staff maintaining the code base today. They have had no other choice.
> If anything, joining forces with someone who is not a competitor but using
> the same tool set will lighten their load.
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593
> http://www.theminimumyouneedtoknow.comhttp://www.infiniteexposure.nethttp://www.johnsmith-book.comhttp://www.logikalblog.comhttp://www.interestingauthors.com/bloghttp://lesedi.us/http://onedollarcontentstore.com
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>


-- 
Best regards,
Vlad
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

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

[Roland Hughes]

On 10/17/2017 12:54 PM, interest-requ...@qt-project.org wrote:

On ter?a-feira, 17 de outubro de 2017 08:11:13 PDT Roland Hughes wrote:

The bug tracking system is under our control - it will not just
disappear (from our perspective).

Oh yes it will!

Speaking as someone who has heard that soo many times before, let's
just count a few for Qt shall we.

The Trolltech bug database was never going to just disappear (from our
perspective). It did. A tiny fraction of the bugs migrated to the new
system but most were mass exterminated with

The TT TT was not a public database. It existed internally only. When we
switched to a public bugtracker, we could only export some entries since many
had confidential customer information. Those that were exported had to be
review by a person to make sure we were not violation any NDAs or
confidentiality.

That's the same reason why the code repository starts with Qt 4.5, not earlier
versions.


"The version this bug is reported against is no longer supported..."

The Nokia bug tracker was never going to just disappear (from our
perspective). It did. Few, if any of the older bugs made it into the
current database. Most were mass exterminated with

There was no Nokia database. We switched straight from the internal tdb
(that's what it was called) to JIRA.
There was a Nokia bug base as well, at least for a while. I and others 
entered bugs into it back in the day. Your argument also re-enforces a 
great many bugs "simply disappeared."



I hear from quite a few companies in similar boats. They started
development for a medical/industrial device which had a lengthy
testing/approval process, filed bug reports for that version only to see
them rot or fall victim to a mass extermination.

Most open source projects don't support old versions, since they don't have
the manpower to do so.


The current owners of Qt and the current OpenSource maintainers don't
offer or seem to understand the concept of an LTS (Long Term Support)
version. They are constantly pursuing script kiddies and that worthless
QML instead of maintaining the base which built them. This will soon
force a fork in the OpenSource project. One which rips out all of the
QML and focuses on nothing but bug fixes for 12 years. Yes, 12 years.

Again, offence taken.
Take all of the offense you want. Medical devices and industrial 
controls need LTS versions, not resource hogging QML features. Qt's 
chasing of the idiot phone market which has 6 months at best life spans 
is alienating and chasing away the very industries which made Qt successful.


I don't know who plans on forking. There's no such division in the community,
so any attempt to do so will probably start with very few developers. Almost
certainly, fewer than critical mass to maintain the codebase.

See TQt (Trinity Project) for an example of a fork attempt.
It's easy to fork something you have been maintaining internally for 
years. There _IS_ such a division. You don't know about it because they 
don't come here. They justifiably believe they've been abandoned. The 
relentless pursuit of "new cool features" to please the phone crowd is 
causing the much larger medical device and industrial control industries 
to create their own LTS.


How many questions have you seen on here over the past 18 months about 
Qt 3? That project Harmman (sp?) calls about periodically sells north of 
a million units per year and the company is maintaining Qt 3 on its own 
so they can make minor product enhancements which don't have to go 
though multi-year clinical trials. They aren't the only calls I get 
about products using Qt 3, 4.2, and the most likely soon to be orphaned 
(if not already) 4.8. Every company I am contacted about using earlier 
versions has their own staff maintaining the code base today. They have 
had no other choice. If anything, joining forces with someone who is not 
a competitor but using the same tool set will lighten their load.


--
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