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

[Sze Howe Koh]

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"?

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].


[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? :-)


> 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.


> 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)


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]


[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.


Regards,
Sze-Howe

[4] e.g. https://bugreports.qt-project.org/browse/QTBUG-35846
[5] e.g .https://bugreports.qt-project.org/browse/QTBUG-33904