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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
