I've never seen it claimed that voting matters 1 iota.
I guess what we're asking for here is more prioritization transparency?
Sent: Thursday, September 22, 2016 at 2:27 AM
From: "Vlad Stelmahovsky" <vladstelmahov...@gmail.com>
To: "Jason H" <jh...@gmx.com>
Cc: interest <interest@qt-project.org>
Subject: Re: [Interest] What don't you like about Qt?
From: "Vlad Stelmahovsky" <vladstelmahov...@gmail.com>
To: "Jason H" <jh...@gmx.com>
Cc: interest <interest@qt-project.org>
Subject: Re: [Interest] What don't you like about Qt?
Actually you can vote for it and promote to other users to vote for it. More votes - more chances issue to be solved
On Wed, Sep 21, 2016 at 2:51 PM, Jason H <jh...@gmx.com> wrote:
This gets at what I don't like about Qt the most: As a user I have no control of where it goes. I can (and do) file bugs and feature suggestions... How they get prioritized, I have no control over. Sometimes it's months, sometimes it's multiple years later, very often it's never (or more correctly, still not implemented yet). This is despite being a paying customer. Once the issue is entered, it might get tagged with the support contract level I am on, but it's effectively out of my hands.
> Sent: Wednesday, September 21, 2016 at 8:35 AM
> From: "Konstantin Tokarev" <annu...@yandex.ru>
> To: "Jean-Michaël Celerier" <jeanmichael.celer...@gmail.com>, "Jason H" <jh...@gmx.com>
> Cc: interest <interest@qt-project.org>, "Rob Allan" <rob_al...@trimble.com>
> Subject: Re: [Interest] What don't you like about Qt?>
>
>
> 21.09.2016, 15:28, "Jean-Michaël Celerier" <jeanmichael.celer...@gmail.com>:
> > Hey, there is a lot of interesting points in all these answers; some similars, some not.
> >
> > Maybe a good way forward would be to try to pinpoint the problems more precisely with an online platform such
> > as http://en.arguman.org/ ? Or even just some kind of google doc...
>
> I think wiki page would be a better alternative.
>
> >
> > Starting from there would maybe make it easier for the Qt devs to weigh the "for" and "against" for the stuff that is often mentioned ?
>
> I doubt anyone here is going to weigh anything besides patches submitted to review.
>
> > Instead of having to find specific arguments in 45 mails... And then open some paths for contributions to try to alleviate the problems.
> >
> > My 0.0005 cents
> >
> > Best
> > Jean-Michaël
> >
> > On Wed, Sep 21, 2016 at 1:53 PM, Jason H <jh...@gmx.com> wrote:
> >>> I also can't help making a comparison with two other popular layout
> >>> frameworks: WPF/XAML, and Android/AXML. In both of these worlds, the markup
> >>> language and the "code-behind" class hierarchy of UI elements are
> >>> absolutely equivalent 1st class citizens. Anything you can do in XAML, you
> >>> can also do in the C# code-behind, whether it be creating controls,
> >>> changing their properties, altering layouts, etc. Likewise in Android/AXML,
> >>> I can (if I choose) create FrameLayouts, RelativeLayouts, TextViews, etc in
> >>> code, and arrange them and manipulate them any way I like, as an
> >>> alternative to creating an AXML designer layout.
> >>>
> >>> It seems unfortunate that Qt Quick doesn't take this approach, and that the
> >>> "code-behind" experience is so limited. One reason that I've heard why it
> >>> might have been done this way is that a rich and fully public C++ interface
> >>> may have hamstrung the developers too much, as there would be constant
> >>> breaking changes from one release to the next. If that's true then I guess
> >>> I understand that, but I would still rather put up with a rich C++
> >>> interface that had breaking changes at new releases, than the relative
> >>> limited C++ interface we have now.
> >>
> >> I'm not sure I follow. Declarituce UI is in. QML, React (+JSX) give you decaritive layouts. It convergent evolution of stucture±properties+code
> >>
> >> XAML, WPF, Qt Widgets all have structure and properties but no code. You've got to create the objects then in another context, assign code to them.
> >>
> >> If you are taking about how QQuickItems wrap C++ my understanding is that's because of the scene graph. My perspective is that the C++ side is better before I'm always having to drop from QML to C++ to expose stuff for QML. So I really don't understand your issue?
> >> _______________________________________________
> >> 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
>
>
> --
> Regards,
> Konstantin
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Best regards,
Vlad
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
