The most important bits are the X-KDE-Library and X-KDE-PluginInfo-Name, they are the "glue" between your class and plasma, without it, nothing will start. For X-KDE-PluginInfo-Category, refer to the PIG.

The header file

This is the example header file, I will add lots of comments in the code to explain everything.

// This is the command that links your applet to the .desktop file
K_EXPORT_PLASMA_APPLET(tutorial1, PlasmaTutorial1)

endif

QRectF boundingRect()

The boundingRect() function tells plasma the actual size of the plasmoid, this is important because we need to know how much space is taken on screen.

Tip

If you have issues with your plasmoid leaving pixels behind when dragging this is almost always a result of a incorrect boundingRect()

void paintInterface(...)

You could call this the main function, since this paints the plasmoid on screen, here you define how you want your plasmoid to look.

K_EXPORT_PLASMA_APPLET ( <name>, <class> )

This is a small but very important part, this links your classname to the applet name in the .desktop file, if your applet doesn't seem to be loaded than chances are there is a difference between this and your .desktop file

Tip

The K_EXPORT_PLASMA_APPLET adds "plasma_applet_", please pay attention to this when setting up your .desktop file to avoid a name difference

The actual work file

Here is the body of the function, again with a lot of comments in between.

Plasma/Svg

As you can see in the example code where using the Plasma::Svg object, there are some important things to note here.

First we're using a relative path widgets/background which causes Plasma::Svg to use Plasma::Theme to locate the SVG data. While Plasma::Svg does support loading arbitrary files when passed an absolute path, use relative paths from the theme as often as possible as it makes Plasma skinable and the individual plasmoids look like a combined whole instead of a group of separate unrelated applications. You can see a list of available image components on the Plasma Theme page.

Next, note how we set the content type of the SVG object to Plasma::Svg::SingleImage. This is actually the default so technically we didn't have to set it manually. It tells the SVG object that the what we have loaded is a single image in the file.

The alternative option, Plasma::Svg::ImageSet tells Plasma::Svg that there are multiple individual images in the SVG file. For instance, one might use this method to store a deck of cards in one SVG file. This is useful since we only require a single SVG file to hold all the images.

In either mode, Plasma::Svg can be used to draw a subset of the SVG file by passing it an element id that appears in the SVG document. As a good example, if you open the clock.svg file that ships with the default theme, you will see that it has a background, 3 handles (hour, minute and seconds) and a foreground (the glass). Due to the ability to put all the elements in one file the SVG file shows a clock. This is much nicer for artists compared to editting 5 separate files that they have to imagine on top of each other, and much nicer for performance as only one SVG renderer and one file read from disk is necessary.

setDrawStandardBackground(bool)

Since drawing a background is a common function there is fast and easier way of doing it. By adding setDrawStandardBackground(true) to the code, the default Plasma background gets drawn behind your plasmoid. This not only saves you time and code, but creates a more consistent presentation for the user.

failedToLaunch()

If for some reason, the applet fails to get up on its feet (the library couldn't be loaded, necessary hardware support wasn't found, etc..) this method returns true. Using this function gives your application a chance to cleanup before quiting.

setFailedToLaunch(bool, QString)

When your application is unable to start, this function allows you to inform Plasma and give an optional reason why. Plasma will then draw a standardized error interface to inform the user of the situation and your applet will not be called upon to do any drawing on its own from that point forward. If your plasmoid becomes more complex and depends on multiple factors this is the nicest way to cleanup.

dataUpdated

If you would connect to any of plasma's data-engines you would have to implement a function called dataUpdated in your plasmoid. The latter is called if the data-engine sends you data, i.e. your plasmoid should recalculate its contents.

Building it all, the CMakeLists.txt

Finally, to put everything together you need to build everything, to tell cmake what needs to go where there is the CMakeLists.txt file.