On Jul 4, 2012 1:18 AM, "Attila Csipa" <q...@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.rutle...@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
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
