Planning merging the single qqml engine

[Ivan Čukić]

While I'm usually more conservative, I do think that something more
decisive should be done in this case (and cases like these). While we
do not want to break everything with each new release (wink wink ghm
ghm nudge nudge), I don't think we want to support every
not-still-preferred-approach-of-implementing-something we made before
indefinitely.

If there are important 3rd-party plasma 5 applets (are there?) that we
really need to keep back-compatibility for, I'd propose this:

 - make it opt-in (as Marco says)
 - deprecate it
 - report notifications to the user 'this applet might make your
desktop unstable' for all used applets that haven't opted-in - this
would serve as a notification both to the users and the developers of
said applets
 - schedule marking the support for these applets for the release
after next, or something.

Cheers,
Ivan




On 18 May 2015 at 21:53, Marco Martin <notmart at gmail.com> wrote:
> On Monday 18 May 2015, Mark Gaiser wrote:
>> Anyway, with that attribute you let the applet developer OPT-IN in for
>> shared engine. Setting that attribute can be easily forgotten. If anything,
>> they should OPT-OUT thus by default use the shared engine.
>> Perhaps a attribute like this is more appropriate?:
>> X-Plasma-RequiresOwnQmlEngine=true
>>
>> or something alike.
>>
>> I'd definitely go for OPT-OUT (defaults = use shared engine).
>
> no, because the key here is retrocompatibility, old applets have to work as
> is.
> it's true that this makes it error prone, but that's the ugly need :/
> otherwise there wouldn't be any reason for supporting both modes
>
> --
> Marco Martin
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel



-- 
Cheerio,
Ivan

--
While you were hanging yourself on someone else's words
Dying to believe in what you heard
I was staring straight into the shining sun