[Panel-devel] thoughts on applet loading

[Aaron J. Seigo]

howdy...

today i sat down and put my thoughts together for how to load applets. 
currently in kicker every applet has a .desktop file and i think this makes 
lots of sense. it gives us access to the i18n infrastructure and allows us to 
gather basic information without having to actually load and instantiate any 
plugins.

the new twists are:

	- multiple languages
	- plasma engines
	- we want all extensions to be external to the plasma binary

that last point means pretty much everything needed to load an applet needs to 
be in libplasma. i committed some initial code (and unit tests) today.

AppletInfo
----------------
as it does now, AppletInfo will wrap the .desktop files to provide abstraction 
and ease of implementation elsewhere. what has changed is that they are no 
longer specific to an instatiated applet as they are in kicker, but specific 
only to one given .desktop file (so it can be shared amongst all applets of a 
given type, e.g. "the clock" or "the taskbar"). researching how the 
applet-specific usage of AppletInfo was done in kicker, this change won't be 
a problem. the biggest change is that we'll eventually want to do some ref 
counting in AppletInfo (perhaps just cheat and use KSharedPtr ;) and that 
applets will have to keep track of the name of their config file themselves.

Multiple Languages
----------------------------
in the .desktop files, there is a new entry (X-KDE-LanguageBindings) that the 
applet can set to note which language it is written in. it defaults to 
"native" which means "compiled to the native architecture", e.g. C++. these 
we can just use the old dlopen-style techniques.

for those that specify another language, the language manager will be asked to 
ensure the language bindings are available, loaded and available.

Plasma Engines
----------------------
each applet will provide an initialization object which will provide at least 
two facilities: return a QStringList of plasma engines it requires, and a new 
instantiation of the applet. this init object would become the new plugin 
interface to applets from the perspective of the applet loader. it would also 
make it easy to house multiple applets in a single library / file and extend 
the pre-instantiation tasks around applets

once the init object is loaded, the list of engines it requires (if any) will 
be retrieved and each of these engines will be checked for availability and 
loaded. i'm thinking that these too should have an initialization object 
which can provide the engine a chance to do any set up necessary prior to 
usage. this allows us to deliver a set of functionality that is ready to go 
as soon as it arrives at the applet without it having to do any 
domain-specific init.

Applet Instantiation
----------------------------
so once the language bindings are loaded, the engines are loaded (and any 
bindings for those engines), the applet itself will be instantiated. this 
entire process will be async, so that we can eventually put it in a thread on 
its own. the applet loader will return a Job that emits a 
appletCreated(Plasma::Applet*) signal or a appletCreationFailed(Plasma::Job*) 
signal (or sth along those lines; haven't designed those out completeley yet) 
the extension that requested the applet can then connect to. for the 
extension the whole process will be async, so we'll probably want to store 
some basic data in the Job as well, such as where the applet should try and 
be placed (since that information depends on the state of the mouse or other 
cursors immediately prior to instantiation)

Applet Base Class
--------------------------
after going through all this, it seems that there is little value in keeping 
KPanelApplet around in its current state. this will be my next big task.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20050907/f8111b20/attachment.pgp