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
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
