Good news regarding Qt 5.5

[Hausmann Simon]

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?

The url interceptor is bothersome anyway of you think about it. It is a bare pointer you can set one the engine any time, and at this same time the callback is called from the qml loader thread at - from the gui thread perspective - any time as well. So the callback implementation also has to be thread safe. It probably works by accident if plasma only uses synchronous component loading, but of you enable async loading as an implementation you might run into crashes in the event that the package interceptor isn't thread safe.


Simon

  Original Message
From: Marco Martin
Sent: Friday, May 8, 2015 22:10
To: Aleix Pol
Cc: plasma-devel at kde.org; Hausmann Simon
Subject: Re: Good news regarding Qt 5.5


On Friday 08 May 2015 19:17:32 Aleix Pol wrote:
> > probably could have known that using QQmlAbstractUrlInterceptor was asking
> > for troubles,  but... any idea? :)
> >
> > --
> > Marco Martin
>
> I have no idea.
> Can you push it into a branch? I'd be interested in looking into this.



to try a plasmashell fully loading, one can change the line in plasma-
desktop/containments/panel/contents/ui/main

import "plasmapackage:/code/LayoutManager.js" as LayoutManager
to
import "../code/LayoutManager.js" as LayoutManager

i get the shell to load
to the imprecise memory of system activity monitor, it goes when just started
from  ~150MB to ~90MB here
also startup time to the eye seems slightly faster, so in one way or another
yup, we have to do that

I just don't know how to solve this url resolution without behavior changes

--
Marco Martin