I could also add the enum exposition to Qml, would be nice to have them
inside their own name and a way to auto map int to string value. we always
have to it manually to convert back and forth for available string/int
value. an object that would wrap the enum and have the following properties:

C++ enum

enum TestEnum
  toto = 0,
  titi = 2

Qml exposition

TestEnum.toto -> return int
TestEnum.allKeys -> list of int
TestEnum.allNames -> list of string
TestEnum.keyNameMap -> QVariantMap<int, QString>()

That would save us many manual exposition and we could iterate on C++ enum
value easily

On Mon, Sep 19, 2016 at 4:03 PM, Jérôme Godbout <jer...@bodycad.com> wrote:

> 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

Reply via email to