(→Communicating With Your Application: clear up) |
(→The Shell) |
||
| Line 2: | Line 2: | ||
== The Shell == | == The Shell == | ||
| − | The core of the dashboard's logic is in a KPart in kdebase-runtime | + | The core of the dashboard's logic is in a KPart in kdebase-runtime called '''plasma-kpart'''. This KPart is loaded like any other ReadOnly KPart: |
<pre> | <pre> | ||
// this routine will find and load our Part. it finds the Part by | // this routine will find and load our Part. it finds the Part by | ||
This page looks at the steps it takes to embed a Plasma shell inside of your application as a dashboard or summary page.
The core of the dashboard's logic is in a KPart in kdebase-runtime called plasma-kpart. This KPart is loaded like any other ReadOnly KPart:
KDE TechBase
// this routine will find and load our Part. it finds the Part by
// name which is a bad idea usually.. but it's alright in this
// case since our Part is made for this Shell
KService::Ptr service = KService::serviceByDesktopPath( "plasma-kpart.desktop" );
if (service)
{
// now that the Part is loaded, we cast it to a Part to get
// our hands on it
m_part = service->createInstance<KParts::ReadOnlyPart>(0, args);
if (m_part)
{
// tell the KParts::MainWindow that this is indeed the main widget
// If you have something better to do with the widget, this is where
// you would do it.
setCentralWidget(m_part->widget());
// and integrate the part's GUI with the shell's
createGUI(m_part);
}
else
{
// For whatever reason the part didn't load
KMessageBox::error(this, i18n("Could not instantiate our Part!"));
qApp->quit();
}
}
else
{
// if we couldn't find our Part, we exit since the Shell by
// itself can't do anything useful
KMessageBox::error(this, i18n("Could not find our Part!"));
qApp->quit();
// we return here, cause qApp->quit() only means "exit the
// next time we enter the event loop...
return;
}
There are two ways to approach writing applets, and some thought should go into this before writing your applets.
The first is to use the standard method of writing Plasma applets, and provide a DataEngine which your applets can use to communicate with your application, either via DBus (allowing you to use the applets on the desktop and in other shells) or intra-process signal/slots using a DataEngine provided by the PluginLoader infrastructure.
The second method is to wrap QWidgets inside of a Plasma::Applet using a QGraphicsProxyWidget. This is most useful if your application has an existing dashboard which is not based on Plasma. These widgets would be created within your application, and loaded using the PluginLoader infrastructure.
New in KDE Development Platform 4.6 is a class called Plasma::PluginLoader, a class which contains, unsurprisingly, most of Plasma's plugin loading logic. Plasma::Applet, Plasma::DataEngine, Plasma::Service, and Plasma::AbstractRunner all ask Plasma::PluginLoader to provide these plugins for them, and Plasma::PluginLoader can be subclassed for use by your application. Plasma::PluginLoader itself is a class with a mix of normal methods, static methods and protected virtual methods:
The long and short of this is that application developers can inject their own Applets, DataEngines, Services and other Plasma objects into a Plasma shell and allow them to do things which plugins loaded through KDE's Plugin system could not do. Users of Plasma::PluginLoader also get many things for free, such as the easy loading and saving of applets, which would have to be done manually if an application chose to only use Plasma::Containment::addApplet().
All that a developer needs to do is to subclass Plasma::PluginLoader and implement the internalAdd* methods which they want to provide plugins for.
See kdeexamples/plasma/c++/kpart for an example of these communication methods.
