(→Running Scripts) |
|||
| Line 27: | Line 27: | ||
:Scripts from files can also be loaded using KRunner with "desktop console /path/to/file" or via dbus with | :Scripts from files can also be loaded using KRunner with "desktop console /path/to/file" or via dbus with | ||
<code bash>qdbus org.kde.plasma-desktop /MainApplication loadScriptInInteractiveConsole /path/to/file</code> | <code bash>qdbus org.kde.plasma-desktop /MainApplication loadScriptInInteractiveConsole /path/to/file</code> | ||
| + | |||
| + | == Templates == | ||
| + | |||
| + | Templates are a type of Plasma package that contains a script using the Plasma Desktop Scripting API. Templates can be loaded from other scripts by name and may appear elsewhere in the Plasma UI. This allows common elements to be kept as separate scripts which can be referenced from multiple other places as a way to increase consistency and lower maintenance costs. | ||
| + | |||
| + | The use case that triggered the inclusion of this feature was the desire to make it easy for users to re-create the default panel (whatever that might be). There is a Template called org.kde.plasma-desktop.defaultPanel that ships with the KDE Plasma Workspace which contains the layout for the initial default panel. This is referenced by the Plasma Desktop init script and, because it is marked as a Panel Template in the metadata.desktop file it also shows up to the user in the Add Panels menu. When selected by the user from the menu, the exact same panel that is created on desktop start up is created for them, complete with Plasma Widgets and configuration. | ||
| + | |||
| + | A Template is a small set of files in a specified file hierarchy (or, in Plasma terms, a "Package"). In particular, a Template package contains the following files: | ||
| + | |||
| + | * metadata.desktop: a .desktop file describing the template | ||
| + | * contents/layout.js: a Javascript file containing the actual script | ||
| + | |||
| + | Templates are stored under share/apps/plasma/layout-templates and may be installed using `plasmapkg -t layout_template path/to/package`. Template packages may also be provided as a .zip file with a .plasmalayout suffix. | ||
| + | |||
| + | The metadata.desktop file contains the usual .desktop entries such as Name and Icon but must also contain Type=Service and ServiceTypes=Plasma/LayoutTemplate entries. If the layout is specific to a given Plasma application, such as plasma-desktop, this can be specific using X-Plasma-Shell. X-Plasma-ContainmentCategories defines what kind of layout it is with possible values being panel and desktop. Finally a X-KDE-PluginInfo-Name entry is required to provide a globally unique internal name for the Template. Here is an example of a Template that provides a Panel layout for Plasma Netbook: | ||
| + | |||
| + | <code ini> | ||
| + | [Desktop Entry] | ||
| + | Encoding=UTF-8 | ||
| + | Name=Cool Panel | ||
| + | Type=Service | ||
| + | ServiceTypes=Plasma/LayoutTemplate | ||
| + | X-Plasma-Shell=plasma-netbook | ||
| + | X-Plasma-ContainmentCategories=panel | ||
| + | X-KDE-PluginInfo-Author=Aaron Seigo | ||
| + | X-KDE-PluginInfo-Email=aseigo@kde.org | ||
| + | X-KDE-PluginInfo-Name=org.kde.CoolNetbookPanel | ||
| + | X-KDE-PluginInfo-Version=1.0 | ||
| + | X-KDE-PluginInfo-Website=http://plasma.kde.org/ | ||
| + | X-KDE-PluginInfo-Category= | ||
| + | X-KDE-PluginInfo-Depends= | ||
| + | X-KDE-PluginInfo-License=GPL | ||
| + | X-KDE-PluginInfo-EnabledByDefault=true | ||
| + | </code> | ||
== API == | == API == | ||
Contents |
It is possible to control and interact with a plasma-desktop session using ECMA Script (aka JavaScript). This scripting mechanism exposes containments (Desktop Activities and Panels), widgets and various other aspects of plasma-desktop configuration using the widely known and used ECMA Script language. The QtScript engine is used for the runtime environment.
This document describes the API that is provided along with how to run such scripts in plasma-desktop.
There are three ways that scripts can be executed in plasma-desktop:
| Note |
|---|
| For security reasons, scripts located in the user's home directory will not be run during this phase. |
`kde4-config --path data`/plasma-desktop/updates/
with a ".js" suffix for scripts that have not yet been run. If there is more than one script which has not been run yet they will be executed serially in the alphabetical order of the file names.
A record of which update scripts have been run is kept in the application's config file in the [Updates] group. This means that if the plasma-desktop configuraiton file is removed, all the update scripts will be run again.
| Note |
|---|
| For security reasons, scripts located in the user's home directory will not be run during this phase. |
qdbus org.kde.plasma-desktop /MainApplication showInteractiveConsole
qdbus org.kde.plasma-desktop /MainApplication loadScriptInInteractiveConsole /path/to/file
Templates are a type of Plasma package that contains a script using the Plasma Desktop Scripting API. Templates can be loaded from other scripts by name and may appear elsewhere in the Plasma UI. This allows common elements to be kept as separate scripts which can be referenced from multiple other places as a way to increase consistency and lower maintenance costs.
The use case that triggered the inclusion of this feature was the desire to make it easy for users to re-create the default panel (whatever that might be). There is a Template called org.kde.plasma-desktop.defaultPanel that ships with the KDE Plasma Workspace which contains the layout for the initial default panel. This is referenced by the Plasma Desktop init script and, because it is marked as a Panel Template in the metadata.desktop file it also shows up to the user in the Add Panels menu. When selected by the user from the menu, the exact same panel that is created on desktop start up is created for them, complete with Plasma Widgets and configuration.
A Template is a small set of files in a specified file hierarchy (or, in Plasma terms, a "Package"). In particular, a Template package contains the following files:
Templates are stored under share/apps/plasma/layout-templates and may be installed using `plasmapkg -t layout_template path/to/package`. Template packages may also be provided as a .zip file with a .plasmalayout suffix.
The metadata.desktop file contains the usual .desktop entries such as Name and Icon but must also contain Type=Service and ServiceTypes=Plasma/LayoutTemplate entries. If the layout is specific to a given Plasma application, such as plasma-desktop, this can be specific using X-Plasma-Shell. X-Plasma-ContainmentCategories defines what kind of layout it is with possible values being panel and desktop. Finally a X-KDE-PluginInfo-Name entry is required to provide a globally unique internal name for the Template. Here is an example of a Template that provides a Panel layout for Plasma Netbook:
[Desktop Entry]
Encoding=UTF-8
Name=Cool Panel
Type=Service
ServiceTypes=Plasma/LayoutTemplate
X-Plasma-Shell=plasma-netbook
X-Plasma-ContainmentCategories=panel
X-KDE-PluginInfo-Author=Aaron Seigo
X-KDE-PluginInfo-Email=aseigo@kde.org
X-KDE-PluginInfo-Name=org.kde.CoolNetbookPanel
X-KDE-PluginInfo-Version=1.0
X-KDE-PluginInfo-Website=http://plasma.kde.org/
X-KDE-PluginInfo-Category=
X-KDE-PluginInfo-Depends=
X-KDE-PluginInfo-License=GPL
X-KDE-PluginInfo-EnabledByDefault=true
In addition to the normal ECMA Script API and the Qt-specific extensions (such as signal/slot support) provided by QtScript, the following API is provided for use by scripts.
All of the API below, unless otherwise noted with a version noticed, appear as below in the KDE Software Compilation v4.4.0 and later. API that is not noted as being part of a given class or object is part of the global namespace.
| Note |
|---|
| API compatibility is guaranteed from version to version starting with KDE Software Compilation v4.4.0. |
Starting with KDE SC 4.5, the version number of both the scripting API and the application is available to the script via the following read-only properties:
Activities are the desktop layer in a plasma-desktop session and may contain widgts. In sightly more technical terms, they are desktop containments. Activities can be created, enumerated, modified and destroyed.
New Activities can be created using the Activity constructor, like this:
var activity = new Activity("folderview")
The string passed into the constructor maps to the X-KDE-PluginInfo-Name= entry in the plugin's .desktop file). See the documentation on the Containment object class below.
Read-only properties:
Functions:
Panels can be created, enumerated, modified and destroyed. A panel object combines both a containment as well as the container itself, allowing for full control of things such as where it appears on screen and the hiding features associated with them.
New Panels can be created using the Panel constructor, like this:
var panel = new Panel("dock")
The string passed into the constructor maps to the X-KDE-PluginInfo-Name= entry in the plugin's .desktop file).
Read-only properties:
Functions:
Activity and Panel objects, once created by the script, or as returned by activityById, activityForScreen, or panelById) provide the following read-only properties:
as well as the following read/write properties:
and the following methods:
in the widget's .desktop file
for the default value
In addition to all of the above properties and functions, Panel objects also provide the folowing read/write properties:
Widgets may be enumerated by calling the widgetIds property on a Activity or Panel object. With a widget id in hand, a Widget object can be retrieved by calling widgetById(id) on an Activity or Panel object. New Widgets can be created with add addWidget(String) function provided by Activity and Panel objects.
A Widget object provides the following read-only properties:
as well as the following read-write properties:
and the following methods:
for the default value
for the default value
Read-only properties:
Functions:
Read-write properties:
Read-only property:
Functions:
A rectangle class is also provided for use with Widget, Panel and screen geometry properties and functions.
Read-only properites:
Read-write properties:
Constructors:
Functions: