On 09/23/2016 11:11 AM, Artem Sidyakin wrote:
Digia
From the 1st of May it’s The Qt Company now :)
Thank you for that information.
NOBODY will pay royalties, period
Participating in calls and meetings with customers, I see a different picture.
Having been in IT over 30 years now working as a consultant for I don't
even remember how many companies, both Fortune 50 and those with < 35
people, I have never encountered one. I have encountered thousands which
will spend "reasonable amounts" on toolkits which provide unlimited and
unrestricted use, but not one which would pay per-item royalties.
If one lives long enough you can see the same mistakes repeated at least
3 times. This per item royalty notion got floated during the
mainframe/mid-range go-go days. Pretty much every company which floated
the notion died a quick and horrible death.
During the DOS and GUI-DOS (Windows 3.x and earlier were NOT operating
systems they were launched via C:\win) a whole rash of companies tried
this royalty thing. Developers had no problem paying huge (for the time)
dollars getting commercial grade compilers and tools, but would not pay
one red cent in royalties. I remember having spent big bucks on .RTLink
like many of my clients and most of the Fortune 100. .RTLink decided
none of us had paid enough so they tried to move to a royalty scheme. I
stress the word "tried." Almost overnight the industry switched to
Blinker. You know what? I did a Web search before writing this. Blinker
is _still_ being sold. Yes, people still do DOS development, I turned
down a contract for it less than a month ago. Various DOS flavors run an
awful lot of expensive embedded devices. Stuff which starts at 1/4
million dollars and goes up from there.
http://www.grafxsoft.com/2blinker.htm
Here is the only thing I could find on .RTLink after a 5 minute search
with multiple search engines.
http://corphist.computerhistory.org/corphist/documents/doc-43e9481924779.pdf
The same story is true for pretty much every tool of the day which tried
the royalty path.
arthritic dog running in deep snow called QML
script kiddies
I find the concept of dividing the application to front-end (QML) and back-end
(C++) very convenient and helpful. That was a truly brilliant idea to implement
such concept in Qt.
I used same approach being .NET/ASP.MVC developer back in my days. But I guess,
I’m just a script-kiddy, so it explains.
It was an ill thought out disaster prone to catastrophe leaving massive
quantities of signals firing off into the mist and developers hoping
they don't kill the neighbor's dog. I'm at a client which is suffering
from just such a QML with Agile catastrophe. One developer (who is no
longer here, possibly not employed as a programmer anywhere now) drank
the QML Kool-aid and was making everything in the back end a property
with NOTIFY signals even if it had absolutely NOTHING to do with user
interaction.
Various other developers have come along and tried to clean up this
monstrosity which fails spasticly in the field. (Agile _always_ produces
a catastrophe when used for any system of consequence.)
Guess what? There is no text editor one can use or bag of dried chicken
bones one can shake to identify NOTIFY signals which are unused. One
developer made the mistake of trusting the IDE search. A lot of NOTIFY
signals which were actually in use went away.
Guess what? QML provides zero, count them zero methods of compile time
verification for signal connections. The _only_ way of identifying these
problems is to have a console connected to your embedded devices AND be
watching real close. Despite all of the efforts to provide compile time
diagnostics to the connect() statement, Qt went and added this rotted
fish of an interface called QML which provides _nothing_ to assist
making stable systems lives quite literally depend on.
Just take a look at how badly QML runs on the Raspberry Pi with a quad core and
Gig of RAM.
http://www.logikalsolutions.com/wordpress/information-technology/raspberry-qt-part-12-qml-blows-big-stinky-chunks/
Yeah, this link was here before. Author was asked back then, how about
benchmarking Qt Quick Controls 2? But I don’t remember his answer to that.
I have a stock RPi 3 on my desk and I use it in my development with QML. Cannot
really complain about anything.
Speaking as the author, his answer was the code was up on the site in a
Zip file and those who wanted to try it on a Raspberry Pi using
libraries not in the current Pi repos were welcome to run their own
tests posting the results here. The resounding silence means they
achieved the same sucky outcome.
--
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
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
