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

d3fault d3faultdotxbe at gmail.com
Wed Jul 4 11:00:55 CEST 2012


On Jul 4, 2012 1:18 AM, "Attila Csipa" <qt at csipa.in.rs> wrote:
>
>>replacement. There is no C++ equivalent of much of the functionality
> > in QML, whereas everything you can do in a .ui file, you can do in C++.
> >
>
> 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++.

>Interoperability is of course
> very important, but it's really not about "we will intentionally make it
> suck", but rather that some things are easier to expose to the C++ side
> than others. Long before declarative we had QtScript and QtWebkit which
> were - in those days - even less interoperable, but perhaps they were
> not as cool, so the sour grapes syndrome didn't kick in :) Yes, one
> might have personal preferences regarding the language choice and how it
> interfaces with the rest of Qt, but that doesn't invalidate the concept.

QtScript is app specific and serves a special need. You don't need to use
it for every regular GUI app. Webkit is C/C++, so I'd imagine whatever
interoperability you desire could have been added trivially. I wasn't
around back then.

> 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)

On Jul 4, 2012 1:26 AM, "Shawn Rutledge" <shawn.t.rutledge at gmail.com> wrote:
> QML is itself quite a simple language, if we leave out the possibility
> of using JS handlers; maybe it wouldn't even be too hard to write a
> qmlc which generates C++ code as long as one doesn't rely on any JS
> language features (or by bundling the JS snippets somehow).  I haven't
> tried though; has anyone else?

qmlc would differ greatly from uic in that qmlc would generate a lot more
code than a programmer would ever want to type. UI files are
interchangeable with C++ to the point where .ui files are essentially just
the C++ code in xml form (xml is easier for the designer to parse +
re-generate).

If QML was implemented as a thin JSON layer with an underlying C++ API
(front-end to QtQuick), then qmlc would be more similar to .ui files
(whoop-de-do) and would be interoperable through said C++ API (the biggy).

I do agree that a qmlc is a step in the right direction... or is at the
very least not a step in the wrong direction.

d3fault
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120704/184ec9a1/attachment.html>


More information about the Development mailing list