Discussion:
Interest Digest Wiki instructions for PI cross compile do not work for PostgreSQL support
(too old to reply)
Roland Hughes
2017-10-17 18:11:50 UTC
Permalink
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 soooooo 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
Vlad Stelmahovsky
2017-10-19 09:38:49 UTC
Permalink
QML is not that resource hogging as JS. dont use JS and you'll be fine
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 soooooo 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
http://lists.qt-project.org/mailman/listinfo/interest
--
Best regards,
Vlad
Roland Hughes
2017-10-19 12:43:09 UTC
Permalink
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.
Post by 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
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 soooooo 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.theminimumyouneedtoknow.com>
http://www.infiniteexposure.net <http://www.infiniteexposure.net>
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
<http://www.interestingauthors.com/blog>
http://lesedi.us/
http://onedollarcontentstore.com <http://onedollarcontentstore.com>
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
<http://lists.qt-project.org/mailman/listinfo/interest>
--
Best regards,
Vlad
--
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
Laszlo Agocs
2017-10-19 12:57:21 UTC
Permalink
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-project.org] On Behalf Of Roland Hughes
Sent: torsdag 19. oktober 2017 14.43
To: Vlad Stelmahovsky <***@gmail.com>
Cc: 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 <***@logikalsolutions.com<mailto:***@logikalsolutions.com>> wrote:



On 10/17/2017 12:54 PM, interest-***@qt-project.org<mailto:interest-***@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 soooooo 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
***@qt-project.org<mailto:***@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/interest
--
Best regards,
Vlad
--
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
Roland Hughes
2017-10-19 13:06:26 UTC
Permalink
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.


Post by 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
Of *Roland Hughes
*Sent:* torsdag 19. oktober 2017 14.43
*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.
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
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 soooooo 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
http://lists.qt-project.org/mailman/listinfo/interest
--
Best regards,
Vlad
--
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
--
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
Konstantin Tokarev
2017-10-19 13:49:15 UTC
Permalink
Post by Roland Hughes
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.
Post by Roland Hughes
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.
http://youtu.be/MAfCQ-t7xY0
Post by 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
Sent: torsdag 19. oktober 2017 14.43
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.
Post by Vlad Stelmahovsky
QML is not that resource hogging as JS. dont use JS and you'll be fine
Post by Laszlo Agocs
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 soooooo 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
http://lists.qt-project.org/mailman/listinfo/interest
--
Best regards,
Vlad
--
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
-- 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
http://lists.qt-project.org/mailman/listinfo/interest
-- 
Regards,
Konstantin
Uwe Rathmann
2017-10-19 14:09:16 UTC
Permalink
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 ).
Sérgio Martins
2017-10-19 13:51:26 UTC
Permalink
On Thu, Oct 19, 2017 at 1:43 PM, Roland Hughes
Post by Laszlo Agocs
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
2017-10-19 14:42:54 UTC
Permalink
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."
Post by Sérgio Martins
On Thu, Oct 19, 2017 at 1:43 PM, Roland Hughes
Post by Laszlo Agocs
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
Filip Piechocki
2017-10-19 19:04:42 UTC
Permalink
Post by 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/
Application used here is of course the best candidate for widgets
implementation as it does not use QtQuick advantages.

Do this:

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.
Post by Roland Hughes
Nasty worthless resource pig which exists only to pursue script kiddies.
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 <
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 soooooo 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 <(630)%20205-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
http://lists.qt-project.org/mailman/listinfo/interest
--
Best regards,
Vlad
--
Roland Hughes, President
Logikal Solutions(630)-205-1593 <(630)%20205-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
http://lists.qt-project.org/mailman/listinfo/interest
Roland Hughes
2017-10-19 22:06:43 UTC
Permalink
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 waaaaaaaaaaaaaaaaaaaay 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 Thu, Oct 19, 2017 at 2:43 PM, 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/
<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.
http://youtu.be/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.
Post by 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
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 soooooo 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 <tel:%28630%29%20205-1593>
http://www.theminimumyouneedtoknow.com
<http://www.theminimumyouneedtoknow.com>
http://www.infiniteexposure.net <http://www.infiniteexposure.net>
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
<http://www.interestingauthors.com/blog>
http://lesedi.us/
http://onedollarcontentstore.com
<http://onedollarcontentstore.com>
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
<http://lists.qt-project.org/mailman/listinfo/interest>
--
Best regards,
Vlad
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593 <tel:%28630%29%20205-1593>
http://www.theminimumyouneedtoknow.com
<http://www.theminimumyouneedtoknow.com>
http://www.infiniteexposure.net <http://www.infiniteexposure.net>
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
<http://www.interestingauthors.com/blog>
http://lesedi.us/
http://onedollarcontentstore.com <http://onedollarcontentstore.com>
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
<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
Filip Piechocki
2017-10-20 05:49:58 UTC
Permalink
On Oct 20, 2017 00:11, "Roland Hughes" <***@logikalsolutions.com> 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 waaaaaaaaaaaaaaaaaaaay 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.
Post by 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-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:
http://youtu.be/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.
Post by Roland Hughes
Nasty worthless resource pig which exists only to pursue script kiddies.
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 <
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 soooooo 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 <%28630%29%20205-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
http://lists.qt-project.org/mailman/listinfo/interest
--
Best regards,
Vlad
--
Roland Hughes, President
Logikal Solutions(630)-205-1593 <%28630%29%20205-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
http://lists.qt-project.org/mailman/listinfo/interest
--
Roland Hughes, President
Logikal Solutions(630)-205-1593 <(630)%20205-1593>
http://www.theminimumyouneedtoknow.comhttp://www.infiniteexposure.nethttp://www.johnsmith-book.comhttp://www.logikalblog.comhttp://www.interestingauthors.com/bloghttp://lesedi.us/http://onedollarcontentstore.com
Vlad Stelmahovsky
2017-10-20 07:14:09 UTC
Permalink
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
Post by 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.
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 waaaaaaaaaaaaaaaaaaaay 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 Thu, Oct 19, 2017 at 2:43 PM, Roland Hughes <
Post by 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-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.
http://youtu.be/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.
Post by Roland Hughes
Nasty worthless resource pig which exists only to pursue script kiddies.
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 <
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 soooooo 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 <%28630%29%20205-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
http://lists.qt-project.org/mailman/listinfo/interest
--
Best regards,
Vlad
--
Roland Hughes, President
Logikal Solutions(630)-205-1593 <%28630%29%20205-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
http://lists.qt-project.org/mailman/listinfo/interest
--
Roland Hughes, President
Logikal Solutions(630)-205-1593 <(630)%20205-1593>
http://www.theminimumyouneedtoknow.comhttp://www.infiniteexposure.nethttp://www.johnsmith-book.comhttp://www.logikalblog.comhttp://www.interestingauthors.com/bloghttp://lesedi.us/http://onedollarcontentstore.com
--
Best regards,
Vlad
Uwe Rathmann
2017-10-20 08:20:27 UTC
Permalink
Post by 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
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
Vlad Stelmahovsky
2017-10-20 10:00:32 UTC
Permalink
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
Post by Uwe Rathmann
Post by 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
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
http://lists.qt-project.org/mailman/listinfo/interest
--
Best regards,
Vlad
Roland Hughes
2017-10-20 13:22:19 UTC
Permalink
Post by 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.
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 sooooo
useful in Puerto Rico where many parts only get enough fuel to run the
generator for a couple of hours each week.
Post by Roland Hughes
I was using a Pi-II not a 1. The Pi-II has waaaaaaaaaaaaaaaaaaaay
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*&)(*&)(*&ing 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.
Post by Roland Hughes
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.
Post by Roland Hughes
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.9999999999999% of all situations yet _most_ of
them won't (*^)(*&)(*&ing 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 that is being taught and boom, product failure.
That reminds me, I need to follow up with a what is left of a company in
Indiana who went down the QML route. When I spoke with them several
years ago they were yet another group who believed they _had_ to use QML
as there was no other way. They were 9 months late, couldn't get it
working, looking for someone to "fix" the unfixable. Company had been in
business a long long time but heard they filed bankruptcy recently.

And thanks to the wiki page being done just as well as QML you can't
even cross compile most Qt applications.
--
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
Vlad Stelmahovsky
2017-10-20 13:25:49 UTC
Permalink
is someone pushes someone to use QML as a mandatory or store data into JSON
DBs? Where? How? Its ridiculous.
Post by 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.
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 sooooo 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 waaaaaaaaaaaaaaaaaaaay 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*&)(*&)(*&ing 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.9999999999999% of all situations yet _most_ of them won't
(*^)(*&)(*&ing 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 that
is being taught and boom, product failure. That reminds me, I need to
follow up with a what is left of a company in Indiana who went down the QML
route. When I spoke with them several years ago they were yet another group
who believed they _had_ to use QML as there was no other way. They were 9
months late, couldn't get it working, looking for someone to "fix" the
unfixable. Company had been in business a long long time but heard they
filed bankruptcy recently.
And thanks to the wiki page being done just as well as QML you can't even
cross compile most Qt applications.
--
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
--
Best regards,
Vlad
Roland Hughes
2017-10-20 13:38:38 UTC
Permalink
Post by Vlad Stelmahovsky
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
Jean-Michaël Celerier
2017-10-21 07:09:22 UTC
Permalink
Post by Uwe Rathmann
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
Post by Uwe Rathmann
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
http://lists.qt-project.org/mailman/listinfo/interest
Roland Hughes
2017-10-21 12:33:46 UTC
Permalink
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.
Post by Uwe Rathmann
Post by Uwe Rathmann
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
Post by Uwe Rathmann
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.theminimumyouneedtoknow.com>
http://www.infiniteexposure.net <http://www.infiniteexposure.net>
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
<http://www.interestingauthors.com/blog>
http://lesedi.us/
http://onedollarcontentstore.com <http://onedollarcontentstore.com>
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
<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
Sze Howe Koh
2017-10-19 23:54:08 UTC
Permalink
Post by Laszlo Agocs
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
Loading...