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 <annu...@yandex.ru>
wrote:
>
>
> 19.09.2016, 21:54, "André Pönitz" <apoen...@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@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
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
