Plasma/PlasmoidGuidelines

What These Guidelines Cover

This document is a place to collect all the "do"s, "don't"s and "how to"s for interface elements in Plasma, particularly Plasmoids. These native Plasma widgets should follow some simple guidelines in both style and code to be included in the official widget set for the KDE Plasma workspaces.

Theming and Graphics style

• Applets should use the Plasma::Applet default background
• Only widgets of the libplasma widget set should be used
• If custom widgets are created, they should be styled with svgs from the Plasma theme, using Plasma::Svg and Plasma::FrameSvg
• All text should always be painted using the colors from Plasma::Theme

Behavioral conventions

• Applets should always work in any form factor, Planar, Horizontal and Vertical
• Applets should be tested on all Containments provided in the standard distribution: Desktop, Panel, Newspaper, Search and launch, and Grouping Desktop
• If an applet should look like an icon when it is in a panel (or if it should have a popup anyways) it should inherit Plasma::PopupApplet
• Applets should do just strictly "visualization" related tasks, as much of the work as possible should be done with implementations of Plasma::DataEngine (data fetcing) and Plasma::Service (data writing)

Category Names

The following are acceptable known entries for plasmoids and applets. If your applet does not fall within one of the following categories, leave the category field empty (it will be automatically categorized under "Miscellaneous" for the time being) and contact the Plasma development team to have a suitable category added to the list (at which point you may then use that category).

• Accessibility tools that help those with special needs or disabilities use their computer
• Application Launchers application starters and file openers.
• Astronomy anything to do with the night sky or other celestial bodies.
• Date and Time clocks, calendars, scheduling, etc
• Development Tools tools and utilities to aid software developers
• Education teaching and educational aides
• Environment and Weather add-ons that display information regarding the weather or other environmentally related data
• Examples samples that are not meant for production systems
• File System anything that operates on files or the file system as it's primary purpose, such as file watchers or directory listings. Simply using a file as storage does not qualify the add-on for this category.
• Fun and Games for games and amusements
• Graphics for add-ons where displaying images, photos or graphical eye candy is the primary purpose
• Language add-ons whose primary purpose is language related, such as dictionaries and translators.
• Mapping geography and geographic data add-ons
• Multimedia music and video.
• Online Services add-ons that provide an interface to online services such as social networking or blogging sites. If there is another more appropriate category for the add-on given the topic (e.g. mapping if the applet's purpose is to show maps), even if the data is retrieved from the Internet prefer that other category over this one.
• Productivity stuff for Getting Things Done - eg. todolists.
• System Information display and interaction with information about the computer such as network activity, hardware health, memory usage, etc
• Utilities Useful tools like calculators
• Windows and Tasks managers for application windows and/or tasks, such as taskbars

Packaging Conventions

Unique Naming

Since your plugins and packages will co-exist with everyone else's, it is a good idea to use a naming scheme that eliminates possibility of accidental name collisions.

In the examples below where it referse to [name], consider including an element unique to your project or organization in it. For instance, if your packages accompany an application, consider including the name of the application. Using an organizational or domain name are also possibilities.

For example, if your plasmoid was called "SuperWidget", the [name] might be:

• myapp.superwidget if it comes with the MyApp program
• myorg.superwidget if it is associated with the MyOrg project/company/entity
• net.myorg.foo.superwidget if the domain name associated with the plasmoid's origin is foo.myorg.net

The type of plugin should be used as a prefix, such as:

• plasma_applet_
• plasma_dataengine_
• plasma_runner_
• plasma_wallpaper_

Resulting in a library name such as plasma_applet_org.kde.superwidget.

.desktop Files

Plasma uses a "general to specific" naming system for .desktop files. Following this practice makes it easy to find entries in the file system and keeps things nicely ordered.

In the list below, [name] would most commonly be the plugin name as found in the file. Files autogenerated by ScriptEngines may include additional namespacing information in the file name.

• Animators: plasma-animator-[name].desktop
• Applets: plasma-applet-[name].desktop. Does not matter what language it is implemented in, it should always have the plasma-applet prefix.
• Containments: plasma-containment-[name].desktop
• DataEngines: plasma-dataengine-[name].desktop
• Runners: plasma-runner-[name].desktop
• ScriptEngines: plasma-scriptengine-[type]-[name].desktop where type may be one or more of Applet, DataEngine and/or Runner.

The X-KDE-PluginInfo-Name entry should be namespaced using the organization name, e.g. "org.kde.[name]" or "com.mycompany.[name]" to avoid collisions in the plugin names, which are used to identify the different components in the configuration for saving and restoring layouts and therefore must be unique.

Coding conventions

Kdelibs coding conventions must be used for widgets destined for inclusion in kdebase-workspace. It is also strongly encouraged for widgets in kdeplasma-addons or extragear-plasma, though it is not strictly required. Consistent code style makes it easier for developers to quickly switch with effectivity between working on different widgets while maintaining code consistency.