[Development] Question about Qt's future

[charleyb123 .]

On Mon, Apr 28, 2014 at 4:39 AM, Hartmann Thomas
<Thomas.Hartmann at digia.com>wrote:

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

This is *very* interesting.

I just wanted to re-quote that section that got me to "sit up in my chair":

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


I'll need to think on this.  It seems to be proposing the act of QML<==>C++
binding is for C++ to act on "signals/events" forwarded to it from QML,
because C++ has all the type information (it can "do the job").  I really
like that.

My current generator works well, "wrapping" the C++ types to expose them
natively into QML.  That also works, letting QML "do the job".  However, we
then have expressions within QML (today's JS bound expressions), and as
others have said, those can "sprawl" and become difficult to maintain in
big/complex systems.

In general, I'd prefer to stay in C++ with my strong type information. QML
has strong typing for its internal types (which I think is essential), but
some GUI logic really needs knowledge of the domain-specific types (that's
this discussion).  I'll have to think on how much "essential expression
logic" is really an attribute of the GUI, and whether QML signals/events
exposed to C++ is sufficient to "tool" the GUI workflow.  It's certainly
"different logic" from the rest of the C++ system, so I'd want to separate
it (the C++ signal/event logic that services the GUI, as separate from the
C++ logic intrinsic to the large/complex back-end).

At present, I almost never write JS in my QML.  When the QML starts to get
even "slightly" rich-with-logic, we implement a C++ QML/GUI component to
expose to QML with "knowlege-of" the C++ types upon which it operates (like
custom "domain-specific-controls" that are then loaded as a "plugin").

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140428/e2ffd676/attachment.html>