Re: [Interest] What you don't like about Qt

[Jason H]

That's some brutal stuff. Comments interjected.

> Sent: Friday, October 14, 2016 at 9:40 AM
> From: "Roland Hughes" <rol...@logikalsolutions.com>
> To: "Artem Sidyakin" <artem.sidya...@qt.io>
> Cc: "interest@qt-project.org" <interest@qt-project.org>
> Subject: Re: [Interest] What you don't like about Qt
>
> 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.

You seem to confuse a bad developer, Agile, and QML. The fact is superfluous 
notify goes no where, so that's not the issue. I've used signals successfully 
on high availability HTTP[S] servers.  I don't see how Agile is an issue. A lot 
of older people (which you clearly are) have contempt for Agile. I've forcibly 
been dragged into Agile. I see it as valid, but not without shortcomings. But 
blaming agile for this is not appropriate. It's akin to an ad hominem attack or 
a strawman argument. 

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

This isn't necessarily so. Below the layer of Agile, are standard software 
engineering practices. Agile is just a project management style, it does not 
dictate software engineering practices. It seems that the software engineering 
practices are to blame.

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

Re: [Interest] What you don't like about Qt

[Roland Hughes]

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

Re: [Interest] What you don't like about Qt

[Konstantin Tokarev]

23.09.2016, 22:17, "Jason H" :
>
> Even the old Qt UI files were somewhat declarative, with signal/slot mappings 
> included in the UI file.

This sounds like you are not sure what word "declarative" means. Of course, UI 
file is 100% declarative, irrespectively from if signal/slot mappings are 
included or not. At the same time QML file may be not fully declarative, as it 
can contain imperative JS code.

>
> Here's a tongue in cheek but very informative talk about it: (30min)
> https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
>
> Because QML has rough edges and isn't 100% C++, that's more of an 
> implementation detail, one that can be addressed without throwing the baby 
> out with the bath water. I'm still a fan of Elegant Architecture and MVC and 
> all that, and it still can all be done in QML. It's just that it's easier 
> than ever.
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

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

Re: [Interest] What you don't like about Qt

[Jason H]

> > Actually, the entire industry is moving to declarative.
> 
> Declarative with mandatory bits of imperative Javascript?

Well with blanket statement being admittedly blanket in nature and subject to 
all the caveats therein, yes.

I realize that many of you are embedded engineers, and will forever be behind 
the bleeding edge, and was too until recently. I'm now mobile, which puts me 
out in the forefront of a lot of technology. The web technology is iterating so 
fast these days, but javascript, an absolutely terrible languages invented in 
10 days in 1995, is taking over. Now, everything can be transpiled into JS, and 
run at half speed thanks to ASM.js in a browser.
Angular (MS, GOOG) uses TypeScript (MS) transpiles down to JS. Meanwhile other 
web toolkits like React+JSX are becoming Declarative in nature. QMLWeb is a 
port of QML to the web as well. Even the old Qt UI files were somewhat 
declarative, with signal/slot mappings included in the UI file. 

Here's a tongue in cheek but very informative talk about it: (30min)
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript

Because QML has rough edges and isn't 100% C++, that's more of an 
implementation detail, one that can be addressed without throwing the baby out 
with the bath water. I'm still a fan of Elegant Architecture and MVC and all 
that, and it still can all be done in QML. It's just that it's easier than ever.


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

Re: [Interest] What you don't like about Qt

[André Pönitz]

On Fri, Sep 23, 2016 at 05:13:44PM +0200, Jason H wrote:
> 
> > Not an isolated case. Client after client tells the same story. The 
> > licensing
> > team at Digia must be paid on commission because _every_ use requires a
> > license when you first contact them.
> 
> FWIW, My dealings with the licensing people have been good.
> 
> > What I don't like right now about Qt is the 3-legged arthritic dog running 
> > in
> > deep snow called QML. It was a bastardized concept when first conceived and 
> > it
> > hasn't gotten any better. Nokia started that concept which explains why they
> > are non-existent in the phone market today.
> 
> Actually, the entire industry is moving to declarative.

Declarative with mandatory bits of imperative Javascript?

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

Re: [Interest] What you don't like about Qt

[Artem Sidyakin]

> Digia

From the 1st of May it’s The Qt Company now :)

> because of this attempt to squeeze licensing and royalties out of the general 
> public
> I highly suspect the LGPL3 move was done to help squeeze

So, in your opinion it is totally fair to create “closed” products 
(TiVoization) using Open Source tools and libraries?
That's an interesting approach. Pity, that developer community would argue with 
that.

> NOBODY will pay royalties, period

Participating in calls and meetings with customers, I see a different picture.

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

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

---
Artem Sidyakin

> On 23 Sep 2016, at 12:50, Roland Hughes  wrote:
> 
> Tried replying to this earlier, but didn't see the content come up so will 
> toss in my 0.0003 cents on this thread.
> 
> >>- C++ is difficult, Qt lacks quality bindings for mainstream languages
> - moc (on build systems that don't automate this step)
> - FUD around licensing
> 
> Well, Digia has itself to thank for FUD. I contacted Digia right after they 
> took over Qt for a project I was working on. Yes, yes, we definitely needed a 
> license. It was $5000 per developer and there were no royalties. Oh, no, you 
> as a consultant cannot buy a commercial license and develop a product for a 
> client, whoever's name is on the product must own the license. Less than two 
> months later "owner" of the product contacted Digia directly. Yes, yes they 
> definitely needed a license. It was many thousands of dollars more than what 
> I was quoted AND they had to pay royalties. The bickering went back and forth 
> for a while. Keep in mind this project was a front end for a service. Anyone 
> could download the software but you had to subscribe to the service. Finally 
> the person actually funding the project who was rumored to be Bill Gates' 
> next door neighbor, contacted some lawyers who contacted Digia. No, No you 
> don't need a license, go with God my child.
> 
> Not an isolated case. Client after client tells the same story. The licensing 
> team at Digia must be paid on commission because _every_ use requires a 
> license when you first contact them.
> 
> 
> What I don't like right now about Qt is the 3-legged arthritic dog running in 
> deep snow called QML. It was a bastardized concept when first conceived and 
> it hasn't gotten any better. Nokia started that concept which explains why 
> they are non-existent in the phone market today.
> 
> The desperate grab for licensing revenue has them trying to make Qt all 
> things to all people serving multiple masters. It will fail as everything 
> which came before failed. You have to focus on one or two things and do them 
> well. Remember how Java was going to cure cancer and end world hunger being 
> used within every embedded device on the planet? The VM got so bloated trying 
> to be all things to all people it can't even FIT on the embedded targets 
> which were its original target. Don't tell me about how well it works on a Pi 
> with 1-2Gig of RAM. It was originally targeted at single CPU (not multi-core) 
> embedded processors with under 512Meg of RAM. Before you quibble there are 
> millions of those things shipping in products every year. Not long ago I 
> worked on such a device. It will ship 5-7 million in the next 3 years because 
> it is the replacement/upgrade for multiple devices, one of which has an 
> installed base of 10+ million globally.
> 
> >> FUD you say? From what I see, IPTV industry is massively switching away 
> >> from Qt because LGPL3 is incompatible with clients' requirements.
> 
> 
> A great many reqs hitting my desk are switching to OpenGL and straight C++ 
> because of this attempt to squeeze licensing and royalties out of the general 
> public. I highly suspect the LGPL3 move was done to help squeeze the orange.
> 
> Given the current push for licensing revenue Qt will not be a marketable 
> skill for consultants or employees within 3 years. NOBODY will pay royalties, 
> period. Many will pay for reasonably priced development packages. Some will 
> pay for support/maintenance. None will pay royalties.
> 
> >> * The goddamn 4.8 documentation still popping up prior 

Re: [Interest] What you don't like about Qt

[Roland Hughes]

On 09/23/2016 10:13 AM, Jason H wrote:



What I don't like right now about Qt is the 3-legged arthritic dog
running in deep snow called QML. It was a bastardized concept when first
conceived and it hasn't gotten any better. Nokia started that concept
which explains why they are non-existent in the phone market today.

Actually, the entire industry is moving to declarative. React+JSX is the most recent 
example. If you want the first example, I think it was XUL, the layout engine for Mozilla 
("Seamonkey"? about 15 years ago) and since then it's been attempted in various 
places (Even MS). FWIW, I think Qt's implementation of declarative is hands-down the best 
implementation, and I don't think it can be beat. And that's me, an old QWidget guy since 
2004.

Actually, none of the "industry" is moving to declarative languages. 
Industry being embedded devices without GPU, having 512Meg or less of 
RAM needing to achieve 10 days active battery life (not 10 hours standby)

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

Re: [Interest] What you don't like about Qt

[Jason H]

> Not an isolated case. Client after client tells the same story. The 
> licensing team at Digia must be paid on commission because _every_ use 
> requires a license when you first contact them.

FWIW, My dealings with the licensing people have been good.

> What I don't like right now about Qt is the 3-legged arthritic dog 
> running in deep snow called QML. It was a bastardized concept when first 
> conceived and it hasn't gotten any better. Nokia started that concept 
> which explains why they are non-existent in the phone market today.

Actually, the entire industry is moving to declarative. React+JSX is the most 
recent example. If you want the first example, I think it was XUL, the layout 
engine for Mozilla ("Seamonkey"? about 15 years ago) and since then it's been 
attempted in various places (Even MS). FWIW, I think Qt's implementation of 
declarative is hands-down the best implementation, and I don't think it can be 
beat. And that's me, an old QWidget guy since 2004.

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

Re: [Interest] What you don't like about Qt

[Roland Hughes]

On 09/23/2016 06:18 AM, Konstantin Tokarev wrote:


23.09.2016, 13:50, "Roland Hughes" :
[snip]

What I don't like right now about Qt is the 3-legged arthritic dog
running in deep snow called QML. It was a bastardized concept when first
conceived and it hasn't gotten any better.

I think it isn't OK to attack a work of other people for its mere existence.
QML has large user audience which likes it and makes beautiful applications
with it, and at the same time nobody is planning to kill Widgets anymore.
Every project needs to have its warts identified so they can be removed. 
QML has become a serious wart and it appears Digia is on the path to 
killing or orphaning the C++ stuff when they develop things for QML first.



Nokia started that concept
which explains why they are non-existent in the phone market today.

Nonsense
Believe it or not, it is true. QML didn't pan out for them. Microsoft 
realized just how weak Nokia had become and consumed them to push 
Windows phone which had about the same success as Zune. The side effect 
was kicking Qt out the door to Digia.


https://en.wikipedia.org/wiki/Zune

Windows based "smart" phones are virtually non-existent in sales. The 
only thing keeping Nokia afloat is legacy flip. Sorry, could not quickly 
find a post using 2015 numbers like this post using 2014.


https://techcrunch.com/2015/03/03/led-by-iphone-6-apple-passed-samsung-in-q4-smartphone-sales-1-9b-mobiles-sold-overall-in-2014/

I did find one with a difficult to interpret graph spanning 2010-Q32015 
which shows the dramatic Nokia market loss.

https://www.statista.com/statistics/263355/global-mobile-device-sales-by-vendor-since-1st-quarter-2008/

And this one which kind of spells out what bad decision on top of bad 
decision on top of bad decision has resulted in.

http://www.theverge.com/2015/7/8/8913365/microsoft-lumia-windows-phones-strategy-2015




The desperate grab for licensing revenue has them trying to make Qt all
things to all people serving multiple masters. It will fail as
everything which came before failed. You have to focus on one or two
things and do them well. Remember how Java was going to cure cancer and
end world hunger being used within every embedded device on the planet?
The VM got so bloated trying to be all things to all people it can't
even FIT on the embedded targets which were its original target. Don't
tell me about how well it works on a Pi with 1-2Gig of RAM. It was
originally targeted at single CPU (not multi-core) embedded processors
with under 512Meg of RAM. Before you quibble there are millions of those
things shipping in products every year. Not long ago I worked on such a
device. It will ship 5-7 million in the next 3 years because it is the
replacement/upgrade for multiple devices, one of which has an installed
base of 10+ million globally.

There are many devices having under 80M of RAM available for applications,
and, thanks to Qt, it's possible to develop apps for them as well ;)
Yes, with C++. Not a bloated scripting tool. 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/



[snip]

Over the past 5 months I have seen at least 3 C++ OpenGL reqs in my
inbox for every C++ Qt req. Most of these are coming from sites which
used to send out C++ Qt reqs. The situation has gotten so bad people are
once again started to work with polyForth.

http://raspberryalphaomega.org.uk/2013/02/03/memory-map-thoughts-for-a-bare-metal-system/

I haven't seen polyForth since the 80s but it's coming back.

Wow, that's spectacular!

Well, shocking at least. The Forth dictionary made it almost impossible 
to change jobs. The "core" or "standard" dictionary was very tiny back 
in the day. Every shop developed their own dictionary that most worked 
with. We had a similar problem with COBOL in the 80s. Shops had built up 
massive copy-libs for everything in the name of code re-use. Sadly, it 
made new-to-the-shop COBOL developers nearly useless to the shop for 
months and in some cases years because they had to spend so much time 
learning what was where.


The C++ version of Qt was the first product to actually try to solve 
this problem in a cross platform manner. Java failed miserably at it, 
basically making the COBOL copy-lib problem a global 
Java-class-from-where problem. With C++ Qt it was all under a single IDE 
with a single set of interactive documentation. This trimmed spin up 
learning curves from months to just a few days when bringing developers 
onto projects.


With QML you end up having an incredibly slow running application and 
returning to the "months" time frame spinning developers up on a project.

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

Re: [Interest] What you don't like about Qt

[Tuukka Turunen]

> -Original Message-
> From: Interest [mailto:interest-bounces+tuukka.turunen=qt.io@qt-
> project.org] On Behalf Of Roland Hughes
> Sent: perjantaina 23. syyskuuta 2016 13.50
> To: interest@qt-project.org
> Subject: Re: [Interest] What you don't like about Qt
> 
> Tried replying to this earlier, but didn't see the content come up so will 
> toss in
> my 0.0003 cents on this thread.
> 
>  >>- C++ is difficult, Qt lacks quality bindings for mainstream languages
> - moc (on build systems that don't automate this step)
> - FUD around licensing
> 
> Well, Digia has itself to thank for FUD. I contacted Digia right after they 
> took
> over Qt for a project I was working on. Yes, yes, we definitely needed a
> license. It was $5000 per developer and there were no royalties. Oh, no, you
> as a consultant cannot buy a commercial license and develop a product for a
> client, whoever's name is on the product must own the license. Less than
> two months later "owner" of the product contacted Digia directly. Yes, yes
> they definitely needed a license. It was many thousands of dollars more than
> what I was quoted AND they had to pay royalties. The bickering went back
> and forth for a while. Keep in mind this project was a front end for a 
> service.
> Anyone could download the software but you had to subscribe to the
> service.
> Finally the person actually funding the project who was rumored to be Bill
> Gates' next door neighbor, contacted some lawyers who contacted Digia. No,
> No you don't need a license, go with God my child.
> 
> Not an isolated case. Client after client tells the same story. The licensing
> team at Digia must be paid on commission because _every_ use requires a
> license when you first contact them.
> 

Many of the common questions about licensing are explained in the FAQ: 
https://www.qt.io/faq 

If the use case is a lot different than common ones, it is possible that 
different persons can provide varying opinions. At the end we do find the right 
model for every case - and most of the cases are fine with the common licensing 
terms: https://www.qt.io/terms-conditions 

There is also an online store for application development licenses: 
https://www.qt.io/buy-product 

Yours,

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

Re: [Interest] What you don't like about Qt

[Roland Hughes]

Tried replying to this earlier, but didn't see the content come up so 
will toss in my 0.0003 cents on this thread.


>>- C++ is difficult, Qt lacks quality bindings for mainstream languages
- moc (on build systems that don't automate this step)
- FUD around licensing

Well, Digia has itself to thank for FUD. I contacted Digia right after 
they took over Qt for a project I was working on. Yes, yes, we 
definitely needed a license. It was $5000 per developer and there were 
no royalties. Oh, no, you as a consultant cannot buy a commercial 
license and develop a product for a client, whoever's name is on the 
product must own the license. Less than two months later "owner" of the 
product contacted Digia directly. Yes, yes they definitely needed a 
license. It was many thousands of dollars more than what I was quoted 
AND they had to pay royalties. The bickering went back and forth for a 
while. Keep in mind this project was a front end for a service. Anyone 
could download the software but you had to subscribe to the service. 
Finally the person actually funding the project who was rumored to be 
Bill Gates' next door neighbor, contacted some lawyers who contacted 
Digia. No, No you don't need a license, go with God my child.


Not an isolated case. Client after client tells the same story. The 
licensing team at Digia must be paid on commission because _every_ use 
requires a license when you first contact them.



What I don't like right now about Qt is the 3-legged arthritic dog 
running in deep snow called QML. It was a bastardized concept when first 
conceived and it hasn't gotten any better. Nokia started that concept 
which explains why they are non-existent in the phone market today.


The desperate grab for licensing revenue has them trying to make Qt all 
things to all people serving multiple masters. It will fail as 
everything which came before failed. You have to focus on one or two 
things and do them well. Remember how Java was going to cure cancer and 
end world hunger being used within every embedded device on the planet? 
The VM got so bloated trying to be all things to all people it can't 
even FIT on the embedded targets which were its original target. Don't 
tell me about how well it works on a Pi with 1-2Gig of RAM. It was 
originally targeted at single CPU (not multi-core) embedded processors 
with under 512Meg of RAM. Before you quibble there are millions of those 
things shipping in products every year. Not long ago I worked on such a 
device. It will ship 5-7 million in the next 3 years because it is the 
replacement/upgrade for multiple devices, one of which has an installed 
base of 10+ million globally.


>> FUD you say? From what I see, IPTV industry is massively switching 
away from Qt because LGPL3 is incompatible with clients' requirements.



A great many reqs hitting my desk are switching to OpenGL and straight 
C++ because of this attempt to squeeze licensing and royalties out of 
the general public. I highly suspect the LGPL3 move was done to help 
squeeze the orange.


Given the current push for licensing revenue Qt will not be a marketable 
skill for consultants or employees within 3 years. NOBODY will pay 
royalties, period. Many will pay for reasonably priced development 
packages. Some will pay for support/maintenance. None will pay royalties.


>> * The goddamn 4.8 documentation still popping up prior to any other in
google search.

I actually find that really handy. There is a _ton_ of 4.8 development 
and support going on.


>>* Features being QML-only instead of being usable from C++. I like coding
in C++ (but I agree it's hard).

That should __never__ happen. It screams lack of commitment to the C++ 
world.


Some features not really cross-platform (e.g. in QtMultimedia, 
QAudioDecoder does not work everywhere, same for the 3D audio classes 
when there is no OpenAL).


That is a true violation of Qt culture, at least as I understood it when 
I started with Qt. The whole philosophy of cross-compile-and-go is 
violated there. This brought down many other tool sets over the decades. 
Remember Zinc? Cross platform between MAC, Windows, DOS and OS/2. Then 
it wasn't quite so cross, then it wasn't stand alone, Wind River 
consumed them to build their own proprietary framework.


>> On the other hand you consider waiting periods of 3-4 months for a 
Qt release already as problematic for your way of working. How does that 
fit?


Releases in general are a problem. This is another one of the multiple 
masters Qt is trying to serve and failing for both.


_Most_ serious embedded projects want one proven and stable release. 
This is why you still see so many people hitting 4.8 documentation 
keeping the link high. Due to regulatory and testing requirements some 
of these systems can take up to 7 years before they can legally sell the 
first unit (think surgical robot and clinical trials.) During that time 
period the tool set cannot change. Heck, I posted a link in here