wrt FUD around licensing : here is a recent reddit thread where someone wasn't able to see that QtCreator was actually a free IDE : https://www.reddit.com/r/cpp/comments/54foop/what_is_the_best_ide_for_game_development_on_mac/
> Oh, thank you! Their website was just confusing for me I couldn't figure it out. Best, Jean-Michaël <http://www.jcelerier.name> On Fri, Sep 23, 2016 at 6:59 AM, Vlad Stelmahovsky < vladstelmahov...@gmail.com> wrote: > so the question: how to make it matter? > > On Thu, Sep 22, 2016 at 4:52 PM, Jason H <jh...@gmx.com> wrote: > >> 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? >> 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 >> > > > > -- > Best regards, > Vlad > > _______________________________________________ > 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
