[Interest] What don't you like about Qt?

[Jason H]

1. Qt progresses at a glacial pace, and often neglects the more urgent/parity issues.
- a. As more organizations adopt agile, this becomes all that more apparent. I've got to wait for a year for a code change to hit a release? Sorry, that's just too long.
- b. Basic stuff like controlling the LED flash on mobile will land for C++ but won't be in QML for another year. 
- c. There is no backlog grooming. Stuff like the blurry canvas bug goes on for _YEARS_ (we're still waiting)

2. Qt Development don't seem in-tune with what Qt users need/want.
- a. Development is often focused on new, sexy features, when they haven't finished the previous release (platform parity, QML/C++ parity)
- b. The mobile stack is no longer being developed (maintained yes, developed, no). There is no support for Wake-locks, push notifications, and other missing platform integrations. So the community is left to repeatedly re-develop these essential mobile functions.

3. Qt has too many versions/code-lines
- a. 5.6 (LTS), 5.7, 5.8, and now 5.9 are all actively being maintained. 
- b. The rampant versioning pace has to be creating waste, taking devs away from development and instead spending it on maintenance. 

That being said, Qt is still really great and really does deliver on "Code less, create more". I compare my solutions to my friends' who have a lot of cruft code to satisfy their platform. Qt/QML is the most concise code out there. Look at React+JSX. It's basically QML but with <> ( <Rectangle><Text>text</Text></Rectangle>). So QML I think is the golden standard for declarative languages. Kudos to it's inventors!

What Qt can do better:
1. Switch to Agile, deliver monthly releases
2. Reduce versions being maintained. (You're stuck with 5.6 LTS, but that plus a monthly 5.X release, whatever is current).
- a. Version the Qt modules independently with the X.Y being a snapshot of modules at release.*
3. Work harder on feature parity before release. 

* I realize as a toolkit, Qt historically requires binary compatibility between X.Y versions, and that any app depending on X.Y.z should be able to run on any X.Y, but I think that it is time for that to end. I've seen enough regressions to know that a .Z release can introduce application-breaking change. Also, from a security standpoint, I don't want an attacker being able to run against a previous release with a known vulnerability. Being able to say .Z= (.Z exactly) .Z+ " .X or later" is really the only realistic constraint. The idea that you can run against a previous version than you were built with just invites trouble. Furthermore, these constraints should be up to the app developer.