[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: [Panel-devel] thoughts on applet loading
From: Wade Olson <wade () corefunction ! com>
Date: 2005-09-07 1:12:10
Message-ID: 431E3E6A.3070905 () corefunction ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@kde.org
>https://mail.kde.org/mailman/listinfo/panel-devel
>
>
[Attachment #5 (text/html)]
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Arial">Don't ruin the ending! I was halfway through the
final paragraph of your blog when this landed in my Inbox. Spoiler
alert.<br>
<br>
</font><br>
Aaron J. Seigo wrote:
<blockquote cite="mid200509061903.17001.aseigo@kde.org" type="cite">
<pre wrap="">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.
</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Panel-devel mailing list
<a class="moz-txt-link-abbreviated" \
href="mailto:Panel-devel@kde.org">Panel-devel@kde.org</a> <a \
class="moz-txt-link-freetext" \
href="https://mail.kde.org/mailman/listinfo/panel-devel">https://mail.kde.org/mailman/listinfo/panel-devel</a>
</pre>
</blockquote>
</body>
</html>
_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic