On Wed, Jan 29, 2014 at 12:07 PM, André Pönitz <apoen...@t-online.de> wrote: > On Tue, Jan 28, 2014 at 11:54:21AM -0800, Alan Alpert wrote: >> Why not tell them that QML is native? > > Believe it or not, some people simply dislike the idea of lying.
I dislike the idea of lying, but I don't mind calling things like I see them even when others may have another opinion. > With "native" people usually associate certain properties, like > performance, lack of separate run time environment, seemless blending > with other native libraries and tools, painless deployment using > the same well-trodden path all the other kids take, too. It has all those from my perspective. I must not be one of those "kids" you're thinking of. >> It is just instantiating a tree >> of C++ objects (if you aren't using JS bindings). > > JS is not optional in QML. Some people have argued hard that it should > be an optional layer of JS (and possibly other) bindings on top of > a non-scripted core, but there has been no progress whatsoever. Not > even an effort. It is not an option to decouple the engine entirely, but you can avoid using it and then there's just a bit of memory usage overhead. Bad habit, I know, but performance to me is temporal and not spatial. >> If you do a C++/QML >> app, with C++ for the logic instead of JS, > > This is not possible right now, and not considered "in scope" for > the future. It's possible, and has been the recommended approach, since the inception of QML. >> then the only performance cost over "100% native" will be the startup time. > > Which already would be prohibitive. But as stated above the setup > you suggest (and know to not exist) is not possible anyway. Given the obvious disparity in our perceptions of reality, I have great skepticism of your ability to attribute knowledge to me ;) . -- Alan Alpert _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
