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

[Jérôme Godbout]

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

Good job,
regards,
Jerome


On Mon, Sep 19, 2016 at 2:59 PM, Konstantin Tokarev <annulen at yandex.ru>
wrote:

>
>
> 19.09.2016, 21:54, "André Pönitz" <apoenitz at t-online.de>:
> > On Sat, Sep 17, 2016 at 09:20:43PM +0100, Sérgio Martins wrote:
> >>  Hi,
> >>
> >>  It's not unusual for us developers and contributors to lose
> >>  perspective of what's important.
> >>  After many years spent on very particular implementation details, it
> >>  becomes difficult to see outside of the box.
> >>
> >>  And because we already know the good aspects I'm asking only about the
> bad.
> >>  No need to discuss or reach an agreement, just go ahead and enumerate
> >>  what you don't like.
> >>
> >>  Personally, I don't know (too much time inside the box), but after
> >>  googling these came up frequently:
> >>
> >>  - C++ is difficult, Qt lacks quality bindings for mainstream languages
> >>  - moc (on build systems that don't automate this step)
> >>  - FUD around licensing
> >>
> >>  Please state your top ones, even if it was already stated by someone
> >>  else, so we have an idea about which ones matter more.
> >
> > On the technical side:
> >
> > #1: The very existence of *two* largely incompatible technology stacks.
> >
> > #2: Lack of full C++ access to the stack that currently receives most
> > development attention.
> >
> > [repeat]
> >
> > #6: Mandatory(!) use of JavaScript in said stack, embedded(!) in a DSL,
> > thwarting any claims of being "declarative" and any originally hoped-for
> > benefits for tooling.
>
> 6a. Mandatory use of particular implementation of JavaScript in said stack
>
> >
> > [#7: Incompatitible feature development for both stacks, would be a
> > non-issue if #1 didn't exist]
> >
> > Andre'
> >
> > _______________________________________________
> > Interest mailing list
> > Interest at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
>
> --
> Regards,
> Konstantin
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160919/472d97ff/attachment.html>