[Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

[Attila Csipa]

On 07/04/2012 12:00 PM, d3fault wrote:
>
> > This is a bit of a red herring. You can do everything in the .ui you can
> > do in C++ exactly because there is not that much you can do with it. You
> > can have a fully static QML (without any JS) for the same purpose, but
> > that would make no sense - that would be just syntax switching from XML
> > to JSON without any functional benefit.
>
> It is not a red herring because everything QML brings to the table can 
> theoretically (read: definitely) be done in C++.
>

I'm not a great fan of JavaScript as a language myself, but there is no 
denying that (as someone who wrote their fair share of 
QtGui/QGraphicsView UIs and somewhat loathes .ui-s and the old 
QtDesigner) QtQuick gets the (UI) job done better and faster, esp in 
Qt5. It's a live and let live, there is no need to get all aggressive on 
QML, it's not going to make somehow QWidgets work better if QML/V8 is 
dropped.

> QtScript is app specific and serves a special need. You don't need to 
> use it for every regular GUI app.

The exact same applies for QML. It serves the need of creating visually 
intensive, animated UIs. You don't need need to use it for every regular 
GUI app (and a lot of people, esp on the desktop side, don't).

> Webkit is C/C++, so I'd imagine whatever interoperability you desire 
> could have been added trivially. I wasn't around back then. 

Given the complexity of webkit that's a very bold statement, and the 
language webkit is written is the least of the concerns :)

> > You're not forced to use QML, it's just that for some tasks it's the
> > easiest (and thus recommended) way to go.
> >
>
> This is where you're wrong. It's "use qml or be stuck with last 
> generation raster painted qwidgets". (or make your own)
>

I see no problem with that. At some point someone contributed QWidgets. 
At another point someone contributed the declarative stuff. Open 
projects go where the contributors or interested parties push it, as 
simple as that. With equal level of reasoning someone could say Qt 
should be rewritten as plain C, as C++ is slow/bloated/ugly. And they 
would be just as (not) right - especially as you have to compare 
incompatible metrics (performance vs development time/complexity).

The bottom line is that there needs to be a *clear* benefit (both short 
and long(er) term) in dropping the QML/JS stuff, which so far has not 
been submitted. For example I don't quite understand why the solution to 
the asymmetric availability of certain functionality is the removal of 
parts that DO have it as opposed to exploring how add/expose it to the 
other side.

Attila