[Development] The place of QML

[Donald Carr]

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?

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.

Cheers,
Donald

On Mon, May 14, 2012 at 2:20 PM, d3fault <d3faultdotxbe at gmail.com> wrote:
> On 5/14/12, Turunen Tuukka <Tuukka.Turunen at digia.com> wrote:
>> Just very short comment to this part - Digia, Qt Commercial does also
>> quite significant R&D. Whereas we do have consulting, and support, we do
>> also our share of development. For example we are working in making sure
>> that Qt runs nicely on those platforms that are important to the
>> commercial customers. Some of these are well aligned with Qt Project, for
>> example Win, Mac, Linux, and some we work on our own or together with the
>> OS vendors (mainly embedded and real-time).
>
> not R&D, but thank you for platform testing!
>
>> We are also investing quite
>> much to the releasing and testing, which also benefits the whole Qt
>> ecosystem.
>
> not R&D, but thank you for helping the release + testing process!
>
>> We do a hefty amount of error corrections, and contributions to create new
>> functionality.
>
> not R&D, but thank you for the bug fixes (<3 4.8.1)!!! The 'create new
> functionality' almost counts, except that it's typically only created
> upon request by a commercial customer (or customers). Where's a Qt
> module that Digia has created from scratch just because they 'thought
> it was a good idea and would bring more people to use Qt'? I've seen
> the Charts stuff you guys made... it's just so small compared to
> Nokia's R&D projects: QML/QtQuick. Nokia is in position to be the ones
> pushing R&D... and they are trying too. The problem is that the Nokia
> R&D has the objective of solving Nokias financial problems -- not the
> bettering of Qt as a whole. Anybody could make the argument that
> QML/QtQuick are aimed at bettering Qt as a whole... and I'd agree...
> that's where it is aimed. But it is a miss and the core Qt user
> (developers) want something else/better... but Nokia just keeps on
> trucking along with 'their' vision, blatantly disregarding the core Qt
> user.
>
> I have a question for you over at Digia: is your Commercial License
> agreement with Nokia permanent? If it is permanent, then I could see
> how an R&D department would make sense (hey guys here's a cool idea if
> you want to help Qt: Hardware Accelerated C++ GUI API with Bindings).
> However, if the agreement is only for a few years, your R&D could be
> ripped out from underneath you as Nokia owns all your contributions
> :-P. Nokia could simply choose another support company for their next
> contract term.
>
> I just don't see Digia R&D being the bleeding edge R&D type that Qt
> needs to stay ahead of the game. Digia will focus on/get distracted by
> their core business: client work.
> Prove me wrong (please (and not with words)).
>
>> Digia has been an active participant in the Qt community
>> for well over 5 years. We have created various different solutions with
>> Qt, improved Qt in many platforms and created a hefty amount of code for
>> Qt 4 and Qt 5. We looked back into some numbers and calculated that in the
>> past few years Digia has done well over 3000 contributions to Qt and Qt
>> Mobility making Digia the biggest contributor to Qt after Nokia/Trolltech.
>
> and for that, I thank you. Even though it was done in your own
> interest, thank you. That's the beauty of open source.
>
> I _don't_ want Qt to fork, it's just a [long-term?] prediction. I want
> to eventually be in a position where I am able to contribute to Qt
> (this has nothing to do with Qt and everything to do with me). I want
> to want to contribute to Qt (this has everything to do with Qt). In
> it's current set up, Nokia gets resale rights to my contributions
> ("get our code and run" is not at all what I'm implying. It's more
> like "get our code, profit from it in ways we can't, release it back
> to us under a license where we can't profit from it (in the ways they
> can)"), and is _NOT_ using the profits (however minimal) towards the
> common goals of the core Qt user (which, as polls have shown, is
> currently a Hardware Accelerated C++ GUI with Bindings). This does not
> make me want to contribute. I don't think it is a healthy open source
> project. Err, maybe that's too strong of a way to say it (Nokia or
> not, this project isn't dying! Long live Qt [or whatever it is called
> in the future]!!!). Better wording: Qt is not as healthy as it could
> be. I want to see it thrive. I want to want to contribute... because I
> know that if I want to contribute, others will too.
>
> Atlant: thank you for the story/history lesson
>
> d3fault
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



-- 
-------------------------------
 °v°  Donald Carr
/(_)\ Vaguely Professional Penguin lover
 ^ ^

Cave canem, te necet lingendo
Chasing my own tail; hate to see me leave, love to watch me go