Fails to build against Qt 5.3 dev snapshot

[Alan Alpert]

On Mon, Dec 2, 2013 at 1:52 AM, Marco Martin <notmart at gmail.com> wrote:
> On Monday 02 December 2013, Alan Alpert wrote:
>
>> Oh, are you guys planning to release something on 5.2? I thought you
>> were still in an early development phase. If you're going to release
>> something, we'll have to put QQmlAbstractUrlInterceptor back in - just
>> keep in mind it may be deprecated in 5.3 (if we need to replace it,
>> there's not much way around that...).
>>
>> I'll push the 'revert revert' tomorrow, it would help if one of you
>> can +1 when I do that, maybe mention which release is depending on it.
>
> Not necessarly on 5.2 (probably not..) but since we started to use
> qabstracturlinterceptor we hoped it would stay there on future releases too.
>
> also if it stays as public api but becomes soon deprecated wouldn't help much
> (basically we would base a new feature depending on somethig deprecated from
> day one)
>
> for a decision wether we are going to keep using this or not, we probably need
> to know more what the plans are.
> is that functionality planned to be back in another class, even tough with
> different api, functionally similar?

Now you know why I wanted to pull it back out at the last minute.

The problem is really one of uncertainty (because I'm not doing the
AOT work). I expect that AOT will pre-resolve types, which means that
it will resolve types and compile based on some map in the SDK (it
would have to work against modules that are device specific, can't
just go resolving them at runtime). If we do that, it will move the
functionality to a special handler at that point (which may use the
url interceptor or replace it, unclear).

The ugly part is that this isn't very avoidable. If AOT ends up
resolving types before handing it to an engine under the control of
user code, then QQmlAbstractUrlInterceptor is out of the picture.
Public or not.

> we used qabstracturlinterceptor for two things:
> *denying some imports
> *changing the path resolution on the filesystem of some others (qfilesector
> needs it, or may be used, but would need something like a reimplemented
> select() i think )

Can't you deny imports using file selectors (in a pinch)? Resolve to
/dev/no-access-privileges?

> if on 5.3 there are going to be different (and public&definitive) ways to
> achieve the above two things we can continue to use the private class until
> then..
> but we need that for once the cake is.. a truth :p

File Selectors are public, I just hurriedly backed out all references
to them using QQmlAbstractUrlInterceptor. So it's in a similar
situation, where it may need to get rewritten for 5.3, but the
functionality will be there. Hopefully it will be public and
definitive, at the very least we should have finished the big engine
rewrite bits by then so it'll be easier to add something like this.

Back at the start of the year, when I added
QQmlAbstractUrlInterceptor, I thought engine development pace had gone
down and so it was safe to plug deep into the workings. Development
pace has sped right back up, so that may have been wrong.

--
Alan Alpert