It would be nice to have a Qml modules manager. I mean, where people could contribute to some common independent reusable modules. That would give good kick start to generate quickly some Qml application.
How many of us had to create a drawer Item with animation and self resize, an overlay box, a Qml Popup that can contain any Items into it... Many of us made some great Qml Items or some JS controller that can easily manipulate dynamic objects that could be reused and help Qml in general (just like pip for Python, jQuery plugin listing, ...). The manager would help to centralize and make the modules known by others people and even be improve by community if lucky. Also put the download and rating and you get something that could help give Qml more grip. ________________________________ From: Interest <interest-bounces+godboutj=amotus...@qt-project.org> on behalf of Bob Hood <bho...@comcast.net> Sent: Friday, February 16, 2018 9:53:27 AM To: Qt Interest Subject: Re: [Interest] QML vs Electron I want to thank all the respondents for such an interesting discussion. I think René made some interesting observations regarding the massive community support for JS in term of package managers, frameworks and UI toolkits. I think that is something that really presents a high bar of entry for QML, that everybody wanting to use it must basically roll their own. As I pointed out, coming from a widget-rich environment to something where I must create my own has always kept me from adopting QML as my cross-device framework of choice. I have to focus on writing the interface itself first before I can focus on writing my application logic. With widgets, I drop them in, and only focus on interface writing if I want to customize them. Nikos pointed out: Electron forces you to write the entire application in JS. That kind of struck me. All of JavaScript's flaws notwithstanding, how could writing your application in a single language for all target devices be a bad thing? Couple that with the massive community and its support (as René observed) and I think it is one of the driving factors that are causing frameworks like Electron to rise, and QML to languish as an option. It seems like the Qt Company had a great idea, but once it was realized, they expected that it would just pick up steam on its own without any further effort on their part. Certainly, it has its supporters here, but I can't see it being a viable alternative to things like Electron unless it is fostered by the Qt Company. As René pointed out: It's about growing the ecosystem through marketing and outreach, while lowering the bar of entry by building better primitives and tooling for working with Qt. It is something that the JS world has been exceedingly good at. I would argue the same thing for "QML" if the Qt Company expects more adoption of it. Otherwise, people are turning to easier-entry alternatives like Electron.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
