Binary QML compilation...
-
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...
-
yes you're right, the only warranty for protected code is compiled one... maybe I'll figure something out, like do draw calculations in C++ and leave only dumb rendering in QML so that way, if someone extracts the code, there won't be any really useful code there.
Thanks Andre
-
Hi Raul,
I'm not actually a Troll any more, unfortunately. I don't know why that badge remains on my profile, I'll have to ask to have it removed. Regarding the "out of the box" possibility, well, it's entirely possible (eg, through encrypted sections of the bundle, or something, I guess - although I don't know how such a system would work) but I'm personally not aware of any such efforts. But as I said, I'm not a troll any more, and am not involved in those sort of feature discussions at this point in time, so my knowledge or lack of it shouldn't imply that it is or isn't happening, internally in Digia.
Cheers,
Chris.[Troll badge removed, cheers -MariusG]
