> It would be nice to have a Qml modules manager. www.qpm.io
------- Jean-Michaël Celerier http://www.jcelerier.name On Fri, Feb 16, 2018 at 4:41 PM, Jérôme Godbout <godbo...@amotus.ca> wrote: > 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 > >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
