Planning merging the single qqml engine

[David Edmundson]

On Mon, May 18, 2015 at 8:28 PM, Marco Martin <notmart at gmail.com> wrote:

> Hi all,
>
> I think the branches for the single shared qqmlengine are pretty much ready
> (few cleanups upcoming days), seems pretty stable here.. did someone ran
> the
> branch for a while as well?


Thanks for doing all that.

Now to make you hate me.
I have a crash, https://paste.kde.org/ppeqjl1c1

That's running:
kdeclarative - your branch
plasma-framework - your branch
plsama-workspace - master
(which is pretty close to running latest frameworks with Plasma 5.3)

It's possibly unrelated, but I switched the top two back to master and it
went away.



Other than that, I think code-wise from me it's nearly good to go.

Can I check it's these
https://git.reviewboard.kde.org/r/123736/
and
https://git.reviewboard.kde.org/r/123735/

and the branches in p-w, p-d, are just changing the metadata?

in plasma-workspace TaskDelegate.qml has an import line removed, is that
intended?



In the end i managed to get a single engine for the whole session, views
> included (had to duplicate the View class in plasmaquick and kept the old
> one
> as deprecated for retrocompatibility unfortunately)
>
> the memory save seems pretty good, i *hope* stability improved as well :p
>
> what still uses separed engines are the applet configuration dialogs: this
> is
> necessary because they are supposed to use a different style for the
> qquickcontrols, and being the settings object that decides the style a qml
> singleton (qml singletons are unique by engine), the engine has to be
> different from the desktop/panel. The good thing is that config dialogs are
> instantiated relatively rarely, in most sessions not at all, so shouldn't
> touch too much a "normal run"
>
> Lets not worry about that for now, we've got from super many -> just a
few.
Better to get this stuff merged, than worry about getting it down to 1.

For retrocompatibility the applets unfortunately have to specify explicitly
> they can share the engine in their metadata file (or eventual
> plasmapackage:/
> urls break)
>
> at the moment it's using
> X-Plasma-RequiredExtensions=SharedEngine
>
> but I'm leaning more on the direction of something like
> X-Plasma-MinimumAPIVersion=5.11
>



Out of curiosity, which plasmoids actually need their own engine?

Were they all changed as a bulk find & replace?


> I would like to have all set before frameworks 5.11
>

So that gives us roughly 2 weeks of testing.

Without the plasma-workspace changes coming in 5.4 it doesn't really have
any benefit to the user.
Being a massively miserable grumpy git, I'd rather merge just after 5.11,
giving us 4 weeks of testing.


> thoughts?
>
> --
> Marco Martin
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150518/e065d10e/attachment.html>