Binary QML compilation...
-
Yeah, it was a really sad day for me when I found out that the Brisbane office was being closed, there were some really talented engineers working there and were adding a lot of cool stuff to Quick.
well, I guess that's that, no binary QML until further notice.
I would contribute, but I'm not familiar enough with the Qt source code... I peeked at some stuff once (the network library) trying to understand some async handling, but it was like reading APL code, there's some really black voodoo under the covers, and I feel that the documentation is lacking on how the core works.
Also, if there was a way to find out where that part of the code was being worked, maybe we can all do our part and try to finish it up, according to the post, the code is done, and the part that needs to be finished is the build process.
-
If you really want to work on this just pop in at #qt-labs or development@qt-project.org; people will be more the willingly to help you.
-
I can't go into #qt-labs because the proxy at work has all IRC access blocked, so I'll have to check how to subscribe to development@qt-project.org and ask around
-
freenode listens on ports 6665, 6666, 6667, 6697 (SSL only), 7000 (SSL only), 7070 (SSL only), 8000, 8001 and 8002, so perhaps you can get around the proxy with one of those ports. ref: http://www.freenode.net/irc_servers.shtml
-
oh, there's also webchat: http://webchat.freenode.net/ which should tunnel everything over http
-
nope,
Other ports don't work, as it's a web proxy, so only 80 and 443 are open. And the webchat.freenode.net is blocked.
I really hate web coat proxies, I feel like a f*cking kid being supervised when doing my homework, but hey, it's the only job available at the moment
-
well, in case you haven't found it yet, you can subscribe to the mailing list from http://lists.qt-project.org/mailman/listinfo/development
-
It's probably not a great idea trying to circumvent company filtering of the internet anyway. I know it's a bitch to work with (learned my lesson on my previous job for not checking on that before I came to work there), but actively trying to get around one may jeapardize your job. If you feel treated like a kid there, first try to convince management to lift the restrictions, at least for the developers (explaining that they are blocking useful resources that can help you be more effective), and if that doesn't work: find another job that does treat you like an adult.
-
As a workaround, you can use QRC to build your QML code into the binary.
Internally, QML is compiled into binary data, as this KDAB post neatly explains: "link":http://www.kdab.com/qml-engine-internals-part-1-qml-file-loading/.
-
Thanks for the link @sierdzio
But as you can see on the link I posted at the beginning of this thread, there is already code implemented by the trolls to achieve QML binary compilation.
The only thing that it says is missing, is the integration into the build system so that when you build an application that has QML code, to be able to transparently compile/deploy without having to do anything funny.
The thing is, we have no idea where that code is, or where to start to find out how to finish up on that work.
-
Hi,
It's not quite as simple as Alan said in his original post in that poll thread, unfortunately.
There are a couple of issues.The first is obvious: pointers. The current QML compiler produces compiled data which includes pointers (to type/property caches which can be used to generate QMetaObjects when required), and possibly other things (it's been a few weeks since I looked at the code, and my memory is getting fuzzy already ;-)
Obviously, this would need to change, to using an integer ID, or some other hash key.
The second is less obvious: mmapability. If the compiler output isn't directly mmapable, but instead write it out as some structure which can be read in via QIODevice, you'd probably actually lose time, since it's so inefficient. If it is mmapable, that'd be magic - but then you have platform specificness creeping into your code. That's not a problem (indeed, with the Bundle support that was added to QtQuick2, it's possible that in the future, application developers could provide per-platform precompiled typedata in the bundle, which could be mmaped in as required instead of a compilation step).
In the end, it's certainly possible to implement, but no-one has, yet. It's a fair bit of work to get right, in my opinion - and it's the sort of thing that you really want to get right the first time.
Also, instantiation will, in any event, dominate parsing/compilation in any performance benchmarks, I think.
Cheers,
Chris. -
Ok Chris, thanks for giving us a more detailed answer about this subject.
But then, as far as you know as a troll, is anyone out there considering giving us an out-of-the-box way to protect our QML for distribution instead of just simple qrc bundling which can easily be circumvented? Or is that something that no one hasn't even actually considered?
One of the advantages of Qt is not only portability and performance, but the fact that you actually get compiled code as well, there are many other good, multi platform frameworks, but most of them are like java or .NET, so the code can be easily decompiled, and if you have code you want to protect because of security or IP, then the best way is to compile.
-
If security is your main concern, then I suggest that you might make it harder for attackers by encrypting the QML before including in your resource. Sure, because you need to include the decryption key in your application, it can still be taken out, but at least the QML won't be there for everybody to see too easily, and standard tools won't extract anything useful.
Compiled QML also isn't a guarantee that it won't be broken with a decompiler. There is only so much you can do...
