2. There are still bugs from 5.2 that need fixing.
3. QmlListProperty has a LOT of requests against it. https://bugreports.qt.io/browse/QTBUG-34015?jql=text%20~%20%22QQmlListProperty%22
PS> Like https://qpm.io?
Sent: Monday, September 19, 2016 at 4:03 PM
From: "Jérôme Godbout" <jer...@bodycad.com>
To: "interest@qt-project.org" <interest@qt-project.org>
Subject: Re: [Interest] What don't you like about Qt?
For myself I would love to see those changes (mostly to Qml, the C++ part is fairly striaght forward and we mostly no more used QWidgets):
  1. Ability to extend or declare basic type into Qml (not only QObject), QQuaternion QMatrix4x4 functions are too limited and it's painful to have a singleton to have those methods, would have been friendlier to extend method on those objects. We would love to declare a vector4d plane interface and the like.
  2. Fix bugs (we have reported some bugs since 5.0 that are still open), we are currently stuck into 5.5 because of a bug that appeared. We had to create patch that are still needed for mouse scroll wheel behavior since 5.3
  3. QQmlListProperty and the like be more _javascript_ compatible (length property as alias to count), so we can do typical _javascript_ Array method on them. Also, using long item list is a pain when they do a clear and push back every element back but 1 when removing an item from it!
  4. Multiple Engine into a single application work as long as you don't use any singleton into your qmldir, C++ you can create a singleton per engine living into their own thread, since you get the ptr into argument when the request arrive, but you have no control for the one into qmldir and it seem like a lazy ignored the QQmlEngine* ptr that request it or the thread into which it did happen.
  5. qsTr() that can revaluate when the resource language is modified and not having to make qsTr("myStr") + I18n.revaluate (singleton that we trigger a change on the revaluate value when changing the languages so GUI string get updated).
  6. Clean up of base Application (QApplication, QGuiApplication...) it's so confusing and still have to check what I need from time to time and may end up with the wrong one that will only crash at run time when loading the style of either one (when you mix Qml and QWidgets project you have to change this after adding a single widget of a different type). We still have a QWidget around for Tree View (because let's be thruthful, the Qml TreeView s*** big time) and for Dock Window.
On a positive note:
  • I strongly welcome the new QtQuick Controls style, it was painful and hard to skin everything into QtQuick.Controls 1 (I didn't had the chance to play too much with it yet, stuck in 5.5 but this is great news)
  • DPI independent and scaling. We start using it, cannot wait to upgrade to benefit from it even more, we are .svg all the way already so this will be great for high dpi screen.
Great jobs from Qt team, they had a fast release to make sure they were present in the past few years with the mobile boom. But now, for one, I would welcome a little less features and more rock solid stuff.
P.S: It could be nice to have a centralized source for 3rd party Qt/Qml module (maybe that's already exist I haven't check but it seem like we often reinvent the wheel for Qml Component).
Interest mailing list

Reply via email to