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

[md at rpzdesign.com]

Thomas & Tero:

There is no way that I can make it to the contributors summit, but
Thomas' message might be a important discussion pience when you arrive
in Berlin.

Related to points 5,6,7 of Thomas' message Below:

Is there a class diagram on the current code base?

This would help newbies when trying to contribute to the refactoring
strategy.

The code supporting the QML, JS, and C++ must be layered and sensibly
separated so that people can "opt-in" on various parts at compile/link time.

When respected people like Thiago Macieira put forth the idea that
there is no public API at the C++ level for Scene Graph and other QML
locked in design pieces, that does not smell right.

Where are the unit tests and test benches for the Qt code base?

I have not seen a script that runs the test bench/unit tests for this
large QT code base.  Anybody have insights on that?

Thanks,

Marco


On 4/28/2014 3:26 AM, Thiago Macieira wrote:> Em seg 28 abr 2014, às
08:33:23, Peter Kümmel escreveu:
>>>> ATM the problem is to get started because I don't know much about the
>>>> current architecture of the graphic stack.
>>>> Any hints where to start for a first hello world?
>>>
>>> Maybe a translation from QML to a .ui file could be a first step? That
>>> could work if you use QtWidgets in the QML file.
>> I think we should start on top of the C/C++ part of current QMLv2
stack (if
>> such a thing exists), with some handwritten widget code. Otherwise we
have
>> a QPainter based system which we already have with QWidgets.
>
> Forget about QPainter.
>
> Your first step, it seems to me, would be to add the necessary C++
public API
> to QtQml so you can instantiate new items in the QML graph, then
manipulate
> their properties and bindings, as well as set new JavaScript code and
> expressions. This simply replaces the QML parser, keeping all the
benefits (and
> problems) of the QML language. In particular, it does not extricate
the JS
> interpreter and engine.
>
> If you want to extricate the JS engine, you probably need to move the
Scene
> Graph classes out of QtQuick and into a module that depends only on
QtGui,
> bypassing the QtQml dependency. You'll need a way to insert generic
items into
> the graph. But, at this point, I question: why don't you just use an
existing
> OpenGL scene graph, like Ogle3D?
>
> Once you've got the base API, you can start thinking of writing
widgets again,
> the platform look and feel. If the QtQml dependency was maintained, it
might
> be possible to reuse the code from Qt Quick Components. If not, you'll
> probably need to start from scratch.
>


On 4/29/2014 3:43 AM, Hartmann Thomas wrote:
> Hi,
> 
> On Mon, Apr 28, 2014 at 2:34 PM, André Pönitz <apoenitz at t-online.de> wrote:
>> I think at least three modifications are inavoidable: For one, things that
>> could be written in a declarative way but which currently are only possible
>> using JavaScript, a declarative way should be added. Second, it should be
>> stressed in the documentation (including the examples), that using
>> inline imperative code is naughty. This can be supported by e.g. the QML
>> Designer refusing to operate on such files. People can still do that, but
>> would be on their own. And finally, and that's also acting as a proof that
>> the first two items actually have been done, the JavaScript dependency
>> should be _optional_.
> 
> Can we turn this into action points we _all_ agree on?
> My personal favorites are (In no strict order):
> 
> (1) Identify non declarative parts of Qt Quick and add declarative API (e.g. setting states)
> (2) Document that inline Java Script and mixing declarative and imperative code in one file has its pitfalls in big projects and creates issues for tooling. Explain the difference between pure declarative QML and QMLJS and the impact on tooling.
> (3) Document that accessing ids from other .qml files without any interface (just relying on the fact that they are in the context) creates hard to maintain QML code.
> (4) Writing (more) QML(JS) static analyzers that can check/enforce a proper strict mode for QML.
> (5) Write refactoring tools that help to clean up existing code.
> (6) Fix/cleanup existing demos and examples.
> (7) Investigate how we can improve the interplay of QML and C++. Especially in C++/backend heavy projects.
> 
> As a second step the actual work has to be done of course.
> 
> Kind Regards,
> Thomas Hartmann
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>