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

[Alan Alpert]

On Mon, Apr 28, 2014 at 7:36 AM, Sze Howe Koh <szehowe.koh at gmail.com> wrote:
> On 25 April 2014 18:18, Joerg Bornemann <joerg.bornemann at digia.com> wrote:
>> On 25-Apr-14 04:21, Sze Howe Koh wrote:
>>
>>> I consider QML and JavaScript to be different languages. JavaScript
>>> can be embedded into QML to extend QML's capabilities, just like how
>>> it can be embedded into HTML to extend HTML's capabilities.
>>
>>
>> Yep, I hear people keep repeating the mantra "QML is declarative. It's just
>> QML/JS that isn't." Does that buy us anything tooling-wise? No. Because,
>> even though this thought is true in essence, in practice you have to use the
>> JS part.
>>   People throw handwritten QML files full of clever hacks at Qt Creator's
>> QmlDesigner and wonder why it doesn't fully understand the magic, even
>> though everything is deemed "declarative" (== "toolable").
>
> To check if I've understood you correctly: You've found that
> classifying QML as "declarative" distorts developers' expectations of
> the tools?
>
> Do you think it will help if we rebrand QML as a "markup language" or
> a "multi-paradigm language", instead of a "declarative language"?

One of the original meanings of QML was Qt Markup Language. But markup
implies less interactivity, and multi-paradigm implies that you need
to read several more paragraphs to understand what it is. So while
declarative is not strictly accurate, I feel it captures the spirit
better (for humans, not tools. Tools should treat it as markup, and if
there are any tools reading this I'm sorry to confuse you ;) ).

> Some user interface markup languages (e.g. XAML, MXML, HTML) allow
> imperative code to be embedded within declarative code.
>
>
> On 26 April 2014 23:39, André Pönitz <apoenitz at t-online.de> wrote:
>> On Fri, Apr 25, 2014 at 10:21:04AM +0800, Sze Howe Koh wrote:
>>> On 24 April 2014 00:35, André Pönitz <apoenitz at t-online.de> wrote:
>>> > On Wed, Apr 23, 2014 at 10:50:23PM +0800, Sze Howe Koh wrote:
>>> >> QML is a declarative language
>>> >
>>> > Are you considering sequences of JavaScript statements, especially control
>>> > flow statements, as "declarative"?
>>> >
>>> > Andre'
>>>
>>> Of course not. :-)
>>
>> Right. With the obvious consequence for .qml files containing such.
>>
>> Within a .qml file, JavaScript is in no way an "optional extension" of some
>> "declarative QML language". QML and JavaScript are _inseparably_ tied
>> together in the QML/JS hybrid contents of a .qml file.
>>
>> A quick grep in qtdeclarative/examples/quick/demos e.g. finds the pattern
>> 'if (' in 30 out of 88 .qml files. All nine examples are affected. And
>> that's not "just an accident", as "pure declarative QML" features like
>> ScriptAction, or on{Triggered,Clicked,Loaded,...} handlers _require_
>> immediate use of JavaScript.
>
> To clarify, I do agree with you that QML is extremely limited without
> JavaScript for its intended role in Qt Quick.
>
> It's just that the two of us had applied the label "QML" to different
> parts of the language framework. This is addressed at the bottom of
> this email.
>
>
>>> I was highlighting the fact that their declarative
>>> structures make QML or HTML+CSS good for describing a GUI's looks.
>>> This is in contrast to imperative languages like C++ or JavaScript or
>>> PHP -- I don't want to use any of these to describe a GUI's looks.
>>
>> Not wanting to "use imperative languages like [...] JavaScript [...] to
>> describe a GUI's look" is fine with me, but how on earth is that an
>> argument _in favour_ of .qml?
>>
>> You could have made the point "declarative structures are good for GUI
>> description" for Qt Widget's .ui files, after all, .ui files contents
>> pretty much _is_ declaring layout nesting and property values.
>
> That was not my argument.
>
> My original comment about declarativeness was in response to the
> apples-to-oranges comparison between UnrealScript and QML. [1] Marius'
> point was (I believe), "Epic Games dropped UnrealScript for C++,
> therefore we too should stay with C++ instead of moving to QML". I was
> trying to say that they aren't comparable because UnrealScript is for
> scripting games while QML is for crafting GUIs. I used QML's
> declarative nature to justify my position that it is a GUI-crafting
> language.
>
> My actual argument in favour for QML was that it lets us express our
> intent much more concisely than other languages. This argument was
> made while we were on the topic of "UI development efficiency", with
> Android XML+Java and the Qt Graphics View Framework as the reference
> points. [1, 2]
>
> Note also, I contended that Qt Quick can now fully replace the
> Graphics View Framework, but is not yet ready to fully replace widgets
> [2].

Graphics View wasn't really made for UIs, and for it's intended use
(multi-view MDI CAD programs?) it's still better than QtQuick. Which
was made for UIs, so can replace Graphics View there.

It's the QtQuick Controls module which should fully replace widgets.
But I agree it's not yet ready (and anyone who complains that they'll
still need their C++ widgets for reason X, X is what we're missing
before it's ready ;) ).

>
> [1] http://lists.qt-project.org/pipermail/development/2014-April/016634.html
> [2] http://lists.qt-project.org/pipermail/development/2014-April/016665.html
>
>
>> Trying to make that point for "parts of the contents of at .qml file"
>> (and even admitting that it doesn't hold for "the other parts") is
>> misleading at best.
>>
>>> (Alternatively, one could argue that QML is a hybrid
>>> declarative-imperative language).
>>
>> Alternatively, one could argue that QML is a not-well-defined, non-standard
>> languange largely incompatible with established tools and workflows,
>
> That's what a trailblazer looks like, no? :-)

Yeah, I doubt that they worried about IDE support when C was fresh out
of the gate.

That said, part of the path from becoming a trailblazer to being the
dominant force ruling the world is IDE and tooling support. We want to
improve tooling capabilities wherever we can do so (without
compromising the 'untooled' developer experience - I know they
frequently clash, and the direct dev exp. takes precedence IMHO). This
may require fresh new trailblazing tools, but that's just the nature
of progress.

>
>> with
>> developers not agreeing on fundamental aspects of its nature, costs and
>> benefits... But, hey, which fool would raise such a claim ;-}
>
> These aren't properties of the language itself, but a symptom of the
> lack of rigorous definitions, and a lack of the "full picture" view of
> the technology. These can be addressed with some thought, without
> having to modify the language.
>

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 back on the constructive trail:
>>
>> The meaning of "QML" keeps oscillating between "QML is whatever can be
>> written in a .qml file" and "QML is only the declarative outer layer of a
>> .qml file". Terminology should be clear, and uniformly applied to all
>> audiences (users, marketing, developers)
>>
>> So "someone" should sit down and come up with a single "official" definition
>> of the basics: What is QML, how does it relate to JS, what's the relation
>> to .qml files.
>
> +1.
>
> Deconstructing your list, here are the items of interest:
>
> 1) A scripting language that pre-dates Qt 4.
> 2) A language, heavily influenced by CSS, that lets authors declare a
> hierarchy of objects and the attributes for each of those objects.
> 3) A language that is the composite of (1) and (2). Specifically, it
> uses (1) to express computational logic within the object attributes
> of (2).
> 4) A file format where each file encapsulates exactly one top-level
> object and its child objects (if any), expressed using (3).
>
> (1) is JavaScript.
> (4) is called a "QML file" and has the ".qml" extension.
>
> The label "QML" is sometimes been applied to (2), sometimes to (3). We
> need to decide which, and stick to it once and for all. Some options:
>
> Option A:
> - Call (2) "QML"
> - Find a new name for (3) (QML-JS? QMS?)
> - Change the name and extension of (4) (".qmljs", ".qms", ...)
>
> Option B:
> - Call (3) "QML"
> - Find a new name for (2)

This is the correct one. QML is called QML/JS to remind people that it
has a lot of JS parts so it's not like learning a whole new language.
The QML language itself includes the imperative scripting language,
our own little JS implementation, which is also discussed by itself so
confusion easily occurs.

(2) is practically JSON. When you remove all JS bindings, what's left
is JS values set on properties. Plus some extra type definition stuff
for Qt Objects (which are much more typed than JS Objects). I'd call
it QON, Qt Object Notation, and while it theoretically could exist
separate from QML I don't think there's enough value there for anyone
to do that work (of splitting the QML engine from the QML parser so
that you can parse "pure QON" and create an object tree with no JS
engine involved - this would have to be done without compromising QML
performance which makes the work even harder).

> Any others models/options?
>
> Previously, I called (2) "QML". But after considering how people use
> this language, and studying other markup languages, I've changed my
> mind and think that (3) should be called "QML". Option A is also far
> too invasive a change.
>
> On a related note, do we have an official statement on what "QML"
> stands for? I've only found a blog comment saying "Qt Modeling
> Language". [3]

I think we settled on Qt Meta-object Language, but I forget where it
was "announced".

> [3] http://blog.qt.digia.com/blog/2009/08/21/qt-declarative-api-changes/#comment-4727
>
>
>> http://qt-project.org/doc/qt-5/qmlapplications.html does not suffice. The
>> use of the term "QML" there and on the directly linked pages match mainly
>> the "QML is whatever can be written in a .qml file" concept ("develop
>> your own applications using QML and Qt C++") but sometimes mentions
>> JavaScript seperately ("integrate QML code with JavaScript and C++.").
>
> Agreed. There needs to be more thought given to terminologies used in
> QML [4]. It also feels like API reviews for QML are less rigorous than
> for C++, [5] but that topic is for another day.

Same as in C++, those both depend on the individual reviewer. There's
just less general consensus available for QML, because it's so new, so
I'd recommended adding more reviewers for QML doc/API reviews (and
giving longer for comments before merging) compared to C++ reviews.
But that again depends more on the individual contributor and how big
a rush they feel they're in.

--
Alan Alpert