1. Qt progresses at a glacial pace, and often neglects the more urgent/parity 
- 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.

Interest mailing list

Reply via email to