Good news regarding Qt 5.5

[Simon Hausmann]

On Friday, May 08, 2015 11:37:33 PM Marco Martin wrote:
> On Friday 08 May 2015 20:16:49 Hausmann Simon wrote:
> > Nice - as a plasma user I'm looking forward to the lower memory usage :)
> > 
> > Regarding the url interceptor:
> > 
> > Could you make the feature optional? An applet that needs absolute
> > package:// urls would have to continue to create it's own engine. But
> > using
> > a new constructor perhaps you could introduce new behavior that requires
> > the use of relative urls simply, so that you have to resolve the root item
> > url only once manually in the framework?
> 
> that may be done, and would make most of the stuff work.
> however it would still lose some features, besides the package:/ url scheme.
> 
> one thing is that it forbids loading qml files that are within other applets
> paths, to be sure applets authors don't get ideas :p

I'm not sure that is much of a "feature". All the applets are running in the 
same process and they can contain native code, right? :)
 
> an important thing is some fallbacks of files that package class does:
> for the use in devices, the applets can have device specific qml files,
> 
> so, trying to open stuff.qml,
> contents/ui/stuff.qml
> 
> if the system is configured to be a tablet, would chose instead
> 
> platformcontents/tablet/ui/stuff.qml
> 
> and fallback to contents/ui/stuff.qml if not existent
> 
> we are probably need this a bit more in the future, so I would really love
> to find a way to not lose it

That's a fair point, but isn't that possible with one generic QQmlFileSelector 
or shared interceptor? Once you have an absolute path you can still do 
substitution, regardless of the package maybe?

> but i can't think about other ways to tap into it since only ways i can
> think of is to ave more context in the interceptor which i don't have or be
> able to intercept somehow QQmlContextData::resolvedUrl() (eh, too bad isn't
> a virtual
> :p)

Right, we can't change the signature of the interceptor to add more "context" 
or additional pointers. And I think it would be a very dangerous design, as 
the QQmlContext lives in the gui thread while the selector is mostly called 
from the loader thread.


Simon