Volker spaketh:
> Qt, QtQuick and QML are for developers, and the primary goal is and will be
>> to make it easier for developers to create awesome product. The worst thing
>> we as developers can do is to wait for some "Technical Steering Group" a'la
>> Tizen and LiMo to create a platform that is relevant for us, and even solves
>> (some of) our problems for us. Build products with technologies that exist
>> today to solve the problems that you have today. And from that perspective,
>> Qt and Linux have been beating any HTML5-based technology for years.
>>
>
I agree in the sense that most "standards" are "Design-By-Committee Messes"
that rarely live up to expectations. I also agree with Torvalds that
"successful standards" are merely ubiquitous convention that have been so
successful that they have merely been around long enough to have been
proven-and-adopted (without coercion), and which are merely (later)
"formalized" into a "standard" (of what people were already doing).
In that sense, QML does not need a "standard", nor a "standard's group".
Its success in the marketplace will merely suggest some future social
ritual would "formalize" it into some "standard", and in the meantime
projects would merely adopt it directly because it proved useful. (I
honestly expect this to be the case.)
Mark respondeth:
> <snip, Why impression that QML was mostly for "mobile"?>
>
> That impression comes from the fact that the Qt folks repeatedly promoted
> QML as "the" thing to use for mobile development. And it "could" be used for
> the desktop but that wasn't the aim of it. Or that's the impression Qt folks
> gave me.
>
> Another thing is the compilation step. It's non existent in pure QML apps
> and that was promoted for mobile use as well since now there was no need to
> compile in slow environments. <snip>,
>
> So that's where my impression came from and that's why i'm asking about the
> future of QML since for me (in my mindset) all the promotion of QML along
> with Mobile usage is just not a case anymore. <snip>
>
Not to prolong a QML speculation thread, (but I don't know where else this
topic should be otherwise considered), IMHO there is a strong
mis-understanding as to what *is* QML. It pains me that Nokia&TheTrolls
seem to have not yet "come into their own" on a consistent and sensible
message. (I assert neither is shown thus far.)
In a nutshell: QML is a technology that exposes GUI development through
declaratively-bound-properties-on-objects. It re-invents usage of
screen-real-estate, in opposition to historical GUI development of
"parent/child" division through layouts and nesting. The result enables
better support for multi-touch, animation, richer data-density interfaces,
and declarative approaches that remove the historic
"imperative-update/repaint()" problems. Applications take less code, for
better features, with fewer bugs/errors, with (far) greater development
speed-and-ease by separating GUI development iteration from the business
logic maintenance of properties exposure.
Parallels for "bound-properties-on-objects" (away from historical imperative
programmatic "updates") can be seen in Google's Android, Apple's iOS, and
Microsoft's WPF. Declarative "bound properties" are *the* future, as
asynchronous events in threaded GUIs do not lend themselves well to
imperative approaches. However, IMHO, QML offers the best approach of these
technologies (e.g., it's "best-of-breed").
I speak with no authority (I don't work for any of the companies above), but
this is my impression, and I'm a heavy-desktop-developer with advanced
scientific GUI demands (e.g., large-and-rich interfaces, with little
interest in Mobile). I concede that "more users" would be generally "good"
for QML, but don't specifically fret over the loss of a given user
(especially at this "early-stage").
More specifically, when you review the "alternatives" (look at the abject
terror in the .NET developer world after Microsoft's recent statements about
the "future" of HTML5/Javascript for Win8), IMHO QML is an "easy" pick over
the alternatives, albeit we are in the very "early" stages of industry
adoption.
However, I'll agree with Mark's assertions that previous QML references
emphasized mobile. This is partly understandable (QML re-invented screen
real-estate and event usage, which is critical for mobile), but I agree with
Mark that we'd like to hear more about desktop widget approaches and build
systems/packaging. (If there's a "real" plan, direction, or "best
practices" for things like these, it would be nice to bring that more
"front-and-center", although I concede it's a new paradigm and those may not
yet be sufficiently well understood even by Nokia&TheTrolls.)
Specifically, IMHO, the Meego anouncement doesn't really matter much, but
what *does* matter is that Nokia&TheTrolls need:
(1) A sensible and consistent message regarding *what is* QML and its future
use
(2) A strong-and-successful Qt5/QML launch with accompanying articulation of
this message
...and a strong and ever-maturing QtCreator (QML/C++) is a great additional
step (nice work-and-progress seen on this recently).
--charley