[Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]

[Alan Alpert]

On Mon, Apr 28, 2014 at 2:34 PM, André Pönitz <apoenitz at t-online.de> wrote:
> On Mon, Apr 28, 2014 at 11:12:47AM -0700, Alan Alpert wrote:
>> Yes, I agree that more rigorous and agreed definitions would be
>> helpful. It also takes time, and impedes innovation, so I'm not sure
>> if we're quite mature enough to "nail down" QML just yet. Should be
>> soon though, in the next few years.
>
> To get this straight: After five years of development the "Maintainer" of
> the Qt Declarative module is neither able nor willing to give a simple
> definition of what "QML" is.

Able, yes. Willing, no. The totality of the experience can and should
depend on the reader at this stage.

To put it another way, if I just say what QML "should" be it will be
sufficiently divorced from reality as to be useless. For example,
QtQuick and QML "should" have a good C++ API, and good tooling which
both supports writing the QML/JS/C++ code faster and visually
designing (in strict mode) components made from all three languages,
while always maintaining a live preview on device. That one sentence
requires years of work to implement, and doesn't even touch upon the
primary goal of QtQuick (that skilled developer-designers can create
custom user experiences efficiently). Note that the primary goal of
QML is to support QtQuick in this endeavor.

Until the ideal world is in sight, it's an expedient method to take a
reasonable current state and iterate on it based on user feedback.
Hopefully when we redo this discussion for Qt 6 and QML V3.0, we'll be
where we can look at the gap to the ideal state and cut it into
manageable chunks. I'm willing to give this a try at the contributor
summit, but I still think we're too far away for that to be more
productive than targeting current user pain points directly.

PS: Despite the near infinite gulf to perfection I still think we're
closer than any other UI Framework ;) .

--
Alan Alpert