[Development] Question about Qt's future

[Simon Hausmann]

On Thursday 24. April 2014 14.08.03 André Pönitz wrote:
> On Thu, Apr 24, 2014 at 09:47:50AM +0200, Simon Hausmann wrote:
> > Let's turn this from a blame game into something more productive.
> 
> I will simply assume this includes the readiness to re-consider some
> of the non-technical decisions of the past.
> 
> > The nature of the beast is that we do have two language environments here
> > and they do (and can't) share the same stack, so stack traces will always
> > be separate.
> 
> There are two separate issues here: 1. The requirement to have two sources
> of stack frames, and 2. the specific setup of the JS stack extraction
> machinery.
> 
> Re 1: It is possible to get a single unified stack trace using standard
> tools an application that's wildly mixing languages (in case of GDB e.g.
> C++, C, Fortran, ADA, D, Modula 2 and a few others) _on the same stack_
> _out of the box_. Such a single frame source is ideal from a tooling
> perspective as it allows complete re-use of standard debugging and
> profiling tools, as well as free integration into platform native IDEs
> like Visual Studio or Xcode.
> 
> We could get there, but that would require de-emphasizing the importance
> of JavaScript in the QML/JS conglomerate, i.e. primarily targeting a
> "Pure-Declarative-UI plus C++-Core scenario". I understand that you don't
> want that, but being able to re-use standard tools is the only feasible
> long-term approach.

Ah, is this based on the idea that the .qml files would not contain any code 
but merely describe the UI layout, and all the logic is entirely and 
exclusively implemented in C++ or any other language supported by the same 
compilation and run-time environment? (i.e. eliminate JavaScript from Qml)


Simon