[Panel-devel] thoughts on applet loading

[Wade Olson]

Don't ruin the ending!  I was halfway through the final paragraph of 
your blog when this landed in my Inbox.  Spoiler alert.


Aaron J. Seigo wrote:

>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.
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Panel-devel mailing list
>Panel-devel at kde.org
>https://mail.kde.org/mailman/listinfo/panel-devel
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20050907/5ed574f0/attachment-0001.html