[Development] The place of QML

[BRM]

> From: Donald Carr <sirspudd at gmail.com>

> Please provide a link to your poll when citing it so that people can
> look at empirical data:
> 
> http://qt-project.org/forums/viewthread/16693/
> 
> must be the wrong poll, since that shows QML components being a
> primary point of concern. This is out of a sample set of 110 people,
> which is infinitesimally small in comparison to the Qt user base. It
> would be a stretch to call this a statistically significant poll, even
> though it reinforces my own personally opinion/desires. I assume the
> poll you are citing has a larger sample size?

He did in this e-mail:

http://lists.qt-project.org/pipermail/development/2012-May/003720.html

But the sample sizes are no better than yours - 114/139/19respectively for each poll.
Again, statically insignificant.

It would probably be good for a statistically significant poll to be officially done.
I'd expect that it would probably have a 50/50 split, or may be a 60/40 split in favor of QML
as I do expect there is still a lot of momentum behind the QWidgets and QGraphics* frameworks.
But I doubt that will happen.

> I also have to point out that QML is not intended for fart
> applications, indeed, QGraphicsView would have given you that quite
> heartily. QML will be useful for anyone who wants to have designers
> get proactively involved in the UI/system software development of user
> interfaces for any number of embedded/dedicated devices. Once the
> qmlscene application can run, you can start working directly on the UI
> for the final product. We had many Qt customers who attempted to
> design competitive UI's with QGraphicsView and ended up throwing away
> their work and creating their own canvas type classes from Qt's core
> classes due to fundamental constraints in the graphics view
> implementation. The first thing most people do is come up with their
> own mark up language; XML seems to be popular for this purpose. QML
> gets you there out of the box, only with a format which is (arguably)
> more readable than XML and with (we hope) a much nicer implementation
> than many of our customers will actually produce. QML takes a tricky
> problem and, we/(many customers) believe, solves it elegantly. I
> expect a much higher success rate for many people who decide to use Qt
> and hence QML for their product design. This makes me a very happy
> camper, since I am still committed to the "Qt Everywhere" dream, of
> which the desktop space is one leg.

Interesting tidbit on QGraphicsView. I'm playing around with it now, but not using any thing like that.
Rather, I'm developing some custom widgets that will go into the QGraphicsScene; still learning a lot
in the process - and have a long way to go; but I'm getting comfortable with it now. (That said, I've
only been working with the QGraphics* APIs for about 2 months on and off, perhaps 1 or 2 weeks solid.)
Of course, I am also going this route as the C++ API makes better sense for me, and it leaves open the ability
to later move to the QML API if I wanted.

However, thus far for display I've mostly done customized QWidget derived classes. I still would be except that I have
a use case (some complex display widgets) that benefits from the QGraphics* APIs better.

Ben