<div>Hi,<br></div><div><br></div><div>I've got an idea for upcoming GSoC event. It's based on <a href="http://community.kde.org/GSoC/2012/Ideas#Project:_Lazy.2FAsynchronous_Plasmoid_Inititalization" target="_blank">http://community.kde.org/GSoC/2012/Ideas#Project:_Lazy.2FAsynchronous_Plasmoid_Inititalization</a> . It is not a finished proposal, just a draft of idea and I hope that you can actually help me make it better and more precise :) Also I'd be very graceful to hear any advices about it or just comments, whatever :)</div>
<div><br></div><div>
<p class="MsoNormal" style="margin-left:40px!important"><span lang="EN-US">Proposal
Title: Asynchronous Plasmoid Inititalization</span></p>
<p class="MsoNormal" style="margin-left:40px!important"><span lang="EN-US"> </span></p>
<p class="MsoNormal" style="margin-left:40px!important"><span lang="EN-US">Motivation
for Proposal / Goal:</span></p>
<p class="MsoNormal" style="margin-left:40px!important"><span lang="EN-US">Plasma is
powerful widget engine written on top of Qt libraries which is extensively used
in KDE Software Compilation. It is heart of Plasma Desktop and Plasma Notebook
workspaces which are well-known by lot of people using Linux. Due to
cross-platform nature of Qt libraries, creating and deploying environment based
on Plasma for mobile devices is also possible and is currently realized in
Plasma Active project.</span></p>
<p class="MsoNormal" style="margin-left:40px!important"><span lang="EN-US">All of
those environments have to control a number of running Plasma applets named Plasmoids.
Currently all of those Plasmoids are initialized in synchronous fashion using
only one thread. This leads to longer startup times than necessary, especially
in modern computers running workspaces containing a lot of them. My goal is to
make Plasmoids initialize asynchronously to reduce overall Plasma startup time.</span></p>
<p class="MsoNormal" style="margin-left:40px!important"><span lang="EN-US"> </span></p>
<p class="MsoNormal" style="margin-left:40px!important"><span lang="EN-US">Current Implementation
Details:</span></p>
<p class="MsoNormal" style="margin-left:40px!important"><span lang="EN-US">Plasmoids
are categorized in Containment class’ objects. This class has a private member
ContainmentPrivate with method initApplets(). Inside it, a loop invokes for
each Plasmoid his initialization function. This can be noticed in kdebug
messages showed below.</span></p></div><div style="margin-left:40px!important"><span lang="EN-US"><div><br></div></span></div><div style="margin-left:40px!important">
<p class="MsoNormal"><span lang="EN-US">plasma-desktop(2793)/libplasma
Plasma::ContainmentPrivate::initApplets: !!{} STARTUP TIME 25808319 Applet
"Application Launcher"</span></p>
<p class="MsoNormal"><span lang="EN-US">plasma-desktop(2793)/libplasma
Plasma::ContainmentPrivate::initApplets: !!{} STARTUP TIME 25817795 Applet
"Calendar"</span></p>
<p class="MsoNormal"><span lang="EN-US">plasma-desktop(2793)/libplasma
Plasma::ContainmentPrivate::initApplets: !!{} STARTUP TIME 25818203 Applet
"Hard Disk Status"</span></p></div><div style="margin-left:40px!important"><span lang="EN-US"><div><br></div></span></div><div style="margin-left:40px!important">
<p class="MsoNormal"><span lang="EN-US">Those
messages include current time in milliseconds and it is clearly visible that startup
times of Plasmoids differ. Those times may highly depend on code included in Plasmoid’s
initialization method, regardless of programming language used to program it. Plasmoids
are quite independent of each other (at least at initialization step); there is
no reason to keep initialization in synchronous fashion.</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">My
Implementation Idea Details:</span></p>
<p class="MsoNormal"><span lang="EN-US">Simply I’ll
start from implementing Applet::init() method asynchronously and take care if
nothing goes wrong. If something bad will happen, I will consequently go
through underlying classes and make them run in multithreaded environment. At this time I'll have good knowledge how to rewrite Applet and Containment classes for implementing asynchronous signal-slot mechanism. It will be used to notify Containment object about status of initialization. <span> </span>Last thing I want to do is update
rest of Plasma’s files to make all code work together without any unpleasant surprises.
</span></p></div><div><span lang="EN-US"><br></span></div><div style="margin-left:40px!important">
<p class="MsoNormal"><span lang="EN-US">To achieve
this goal I’ll use classes provided by QtConcurrent namespace. They allow
invoking functions in separate threads using their own thread pool. Amount of
created threads depends on actual needs and available processing units, so solution is flexible and will continue to scale when deployed on multi-core
systems in the future. QtConcurrent is also quite easy to implement and
understand comparing to creating and handling a lot of QThread instances. </span></p>
<p class="MsoNormal"><span lang="EN-US">I am also going
to use existing Plasmoid Viewer application to build simple application which
will allow me to run a number of Plasmoids in separate environment (instead of
only one in Plasmoid Viewer).</span></p></div><div><span lang="EN-US"><br></span></div><div><span lang="EN-US">Well, what do you think about it? <br></span></div><div><span lang="EN-US"><br></span></div>
<div><span lang="EN-US">Best regards,<br></span></div><div><span lang="EN-US"><br></span></div><div><span lang="EN-US">Łukasz Olender<br></span></div><div><span lang="EN-US"><br></span></div>