[Development] The place of QML

d3fault d3faultdotxbe at gmail.com
Fri May 11 12:43:18 CEST 2012


So, I'm supposed to want to contribute an upgraded C++ GUI API ("Yes,
the Qt Widgets module we have in Qt 5 is right now marked as ‘done’,
which means we don’t have anybody actively working on new features for
the module at this point in time. But this can change any day if
someone has some interest or need to do more active development in
this area." -Lars) to this "open source"' project wherein my
components (upgraded C++ GUI API) can be sold alongside your
components (expensive/unnecessary front-end to your efficient
back-end) and I not receive a single dime of it? (That described
scenario also shows how Nokia will receive false confidence in their
QML product. Qt/C++ attracts the real users, QML/"New"/Flashy gets all
the credit). The Qt Contributor's Agreement is very permissive with
what Nokia (and not you or I) may do with any/all code contributed to
the Qt Project. Not only that, but the money earned from Commercial
sales is used against the majority's interest
(http://qt-project.org/forums/viewthread/16693/ is skewed (this one's
biased, but is still more accurate:
http://qt-project.org/forums/viewthread/16465/ ), because "Desktop
Components" is of course the next logical step for the only language
that interfaces with QtQuick. It's playing catch-up with QWidgets
functionality. Additionally, Desktop Components becomes the
unquestionable winner for anyone not paying attention to the C++ vs.
QML "religious war" -some guy on the forums. We need an un-biased poll
that compares the 2 real issues: Qml/Js/Vm vs. Upgraded C++ GUI with
bindings (made it: http://qt-project.org/forums/viewthread/17137/ )).
Sure, Nokia deserves some moneys for Qt. Equally, they should be
obligated to benefiting the majority of their userbase (Interest -
"List for developers who _use_ Qt"). Nokia is for some reason (driven
by a CEO could be the problem) off creating a "Toy Programming
Language" (QML) targeting their mobile lineup when they should be
focusing strictly on their core customers (C++ developers). The ones
who made Qt what it is today.

I'm sure I'm not the only C++ developer that feels this way. It is the
Qt way (how Trolltech intended it before being gobbled up). Now the
direction is meaningless in terms of the money put into it (investing)
and generated by it (commercial license sales). The money is
meaningless because it is being invested in stuff that the
original/true/still-here Qt way wouldn't want it to be invested. It is
being invested in QML/JS/VM. Nokia overpaid in creating QML/JS/VM at
least in terms of their design (maybe they got a great rate on
programmers). The overpaid cost is of course the the JS and VM.

what's wrong with this code (inb4 someone tells me what's wrong with
it -- i'm sure something similar+workable can be devised):
m_SomeDeclaredView.somePropertyWhichIsBeingUsedDeclarativelyInC++ =
Q_BINDING((Q_BIND(m_SomeOtherObject.someProperty1) +
Q_BIND(m_AnotherObject.someProperty2)) /
Q_BIND(m_YetAnotherObject.someProperty3) + aConstantInteger)
Q_BINDING and Q_BIND work precompiler (make note of for later setting
up elaborate signals/slots "binding" functionality) magic and then
evaluate to nothing, just like emit. "non-trivial bindings", that the
QML camp are so proud of, can be implemented purely in C++.

...aside from the fact that it's incredibly ugly?

long term, i see a fork. qt (and derivs) will suffer

one solution to this is a Qt Charity that receives all Qt Commercial
fundings and puts them toward a) support and b) future development
based on "developers who _USE_ qt" 's needs/wants

Nokia can continue to waste money on QML etc while Commercial sales
drive the development of Modern C++ GUI (now hardware accelerated +
bindings in a C++ declarative-like environment) and other things that
are specifically NOT in the interest of Nokia (first-rate QPA
Android/iOS platform plugins for starters). Everybody's happy.

I keep hearing the argument 'well if you want feature x then go
develop it'. Qt is powerful and useful enough that it can propel it's
own development (a charity works perfect here). Nokia is now in charge
of that 'propelling' and is aiming it at their global corporate
interests.... which are QML/Javascript Toy Apps development for mobile
phones. I can't say I blame them, I mean let's be honest... toy apps
are the hottest thing on all of the app markets.

I would like to hear some feedback on the Fork +/ Charity
('Commercial' license providing support only unfortunately (unless
Nokia supports it which we all know wouldn't happen)... can't release
to customers under anything more permissive than LGPL. Stilll it's
permissive enough for most cases (one notable place stands out: iOS
App Store). And sadly that support money is all we'd have for
investing into future development. Still, I think Qt is popular enough
to warrant profits seeing future development). Forking Qt will also
permanently lower the barrier to entry for contributing to the
derivative of Qt (which would have to be renamed obviously) to only
requiring you to release your code under the LGPL... not having to
sign the Qt Contributor's Agreement.

d3fault



More information about the Development mailing list