[Development] Question about Qt's future

[Hartmann Thomas]

Hi,

gluing together C++ and Java Script is currently not always that easy.
The solution I propose is the option to write C++ code in the exact same way you currently write Java Script code.
This means every QML context/component can have a C++ object attached to it that implements a set of methods
that are exposed to QML. The important part would be that C++ would have access to the QML context (e.g. context.get("someID.x"). 

All of this is already possible, if we assume that we handle the context via QVariant function arguments and resolve it on the JS side (someObjectInTheContext.mouseAreaClicked(mouse.x)), but it requires quite a lot of boiler plate code and there is no canonical well documented way how to exactly do this. 
Also the setting of context objects is string based and quite hard to track for the code model (especially if there is more then one engine in the project) for auto completion and code navigation.

What problem does this sovle?

If there is a complex C++ backend there is no glue code needed anymore. There would be no need to expose types from C++ to QML anymore, since it would work the other way around. QML would expose its context to C++.
People could work in nearly the same way as they work with .ui files.  Typically the QML context is not very complex and only consists of a couple of objects, signals and state variables (e.g. currentIndex of a ComboBox). 

Kind Regards,
Thomas Hartmann
________________________________________
From: development-bounces+thomas.hartmann=digia.com at qt-project.org [development-bounces+thomas.hartmann=digia.com at qt-project.org] on behalf of André Somers [andre at familiesomers.nl]
Sent: 28 April 2014 11:57
To: development at qt-project.org
Subject: Re: [Development] Question about Qt's future

Hartmann Thomas schreef op 28-4-2014 11:32:
> Hi,
>
> yes, writting C++ inline in QML would be another "tooling nightmare". Also what is the problem with:
>
> MouseArea {
>      onClicked: companion.mouseAreaClicked();
> }
>
> If tooling creates the companion object for you (In a wizard) and code completion and code naviagtion (F2) works as expected?
>

I'm not sure if I understand what you mean by a "companion" object. Why
exactly do we need another object in the mix? Where does it come from?
Where is exposed to the C++ side of things? What problem is it supposed
to solve exactly?

QML already allows you to specify signals. Would exposing these signals
on the C++ side through the object created by QQmlComponent::create not
be enough? You could then on the QML side bind the handler to signal on
the root object (directly or indirectly), and handle the signal on the
C++ side. Tooling-wise, I _guess_ these signals could be exposed for
code completion and the likes.

But... you can already do something like that. You can already expose a
custom QObject with slots to QML that you can use to bind your handlers
to. Sort of like a UI controller object.


André
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development