Development/Tutorials/Solid/Device Actions

Introduction

When a new data device is inserted or detected by Solid, the hardware awareness framework introduced in KDE Platform 4, it gets added to the Device Notifier (a Plasma widget that is responsible for handling device events), Places list and other relevant areas in the user interface.

Each device has a set of related actions which the user can perform on the device, depending on the device type and its contents. For example, when the media is an audio CD, the Device Notifier may offer to play that CD using Amarok. The default actions are not a part of Plasma Desktop, however; rather, each action is defined by a simple .desktop file that is installed by the application that handles the action (e.g. Amarok in our Audio CD example), and goes away when the application is removed.

You can add your own actions and modify existing ones using the Device Actions system setting module; however, such changes are limited to the user that requests the change. If you want to install a custom action along with your application, you have to dig a bit deeper.

Anatomy of an action

An Action file is a desktop configuration file similar to the following one: [Desktop Entry] X-KDE-Solid-Predicate=OpticalDisc.availableContent & 'Audio' Type=Service Actions=Play;

[Desktop Action Play] Name=Play Audio CD with Amarok Name[fr]=Jouer CD Audio avec Amarok

1. names in other languages

Icon=amarok Exec=amarok --cdplay %f

Actions and devices

The Device Notifier gets the devices and their corresponding actions by interrogating thehotplug Plasma DataEngine. The hotplug DataEngine gets the set of devices from Solid and the set of actions from the subdirectories ./solid/actions relative to the application settings path in KDE. The set of actions pertaining to each device is then obtained by evaluating the Solid Predicate specified in the action against the physical and logical properties of the device; if the predicate holds, the action is included. This is, of course, not limited to Plasma Desktop: any application can similarly query Solid for the same actions.

Action predicates

The predicate for each action is specified in the entry X-KDE-Solid-Predicate. The syntax of the predicate allows to construct an object of class Solid::Predicate out of it.

Atomic predicates can be of the form

• DeviceClass.attribute == value
• DeviceClass.attribute & value

the latter form meaning that the Solid attribute may have a set of values, and the specified value must be a part of that set.

For example, the predicate OpticalDisc.availableContent & 'Audio' means that the device medium is an optical disc and that it contains audio tracks and possibly something else, while the hypothetical predicate OpticalDisc.availableContent == 'Audio' means that a matching device contains audio tracks and nothing else.

Atomic predicates can be composed using the keywords AND and OR and parentheses. In practice, it is easiest to create a custom action with System Settings and peek the description from the custom action desktop file (within the user profile directory).

Executing actions

A matching action can be selected for execution by the user. When that happens, the command line in the Exec key of the action is executed given the device as a parameter. The location and value of the parameter is specified in the following way:

%f

Device mount point location, if applicable

%d

Device special file path

%i

Device identifier, as if returned by the command solid-hardware

So you are free to choose whatever command syntax your application supports. Note, however, that the forms %d and %i are deprecated by the Free Desktop standard and may be discontinued.

Installing actions

You install system-wide actions in the directory where the hotplug data engine will look for them (see above). The action is available immediately after installation.