On Mon, Dec 2, 2013 at 2:00 AM, Marco Martin <notm...@gmail.com> wrote: > On Saturday 30 November 2013, Alan Alpert wrote: >> Hi, >> >> Yes, this was a change on purpose. Sorry for not informing you, as I did >> recall that you were wanting to use it. >> >> The issue is that we're starting to work on ahead of time compilation of >> for 5.3, and we think the url interceptor might get in the way(because >> types and urls can otherwise resolve in different ways at runtime, and >> precompiling the types is the main draw of AOT) . If we do rewrite that >> part of the engine, we'll need to make it more module based instead of urls >> (which would then allow me to provide a similar level of control at the >> module level, which should suffice for the security mechanism we talked >> about). > > btw what is the plan? precompile qml files and caching some kind of binary > file on disk?
Kindof, more like deploying a binary file than caching it. We're planning a separate pre-deploy build step which you'll use for the release deployment of a package or module. Sort of like how QtQuick.Controls bundles all the QML files as QRC for release, but not debug. Sort of like qmlbundle, except we hope to get farther :P . I'm pretty sure that it will be an opt-in deploy time step, everything will continue to work the "same as before" without it. Except that we are in the middle of a major engine rewrite and AOT is probably going to change even more :P. For everything except QQmlAbstractUrlInterceptor (which exposes details a bit too deep in the internals) we aim to maintain compatibility. -- Alan Alpert _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
