Plasma/Vocabulary: Difference between revisions
m (fixed typo "RunnerManger") |
(→More terminology: add content of chapter) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
==Plasma== | |||
Plasma refers to the framework | Plasma refers to the framework upon which | ||
the various Plasma workspaces, | |||
Plasma and KRunner plugins, etc. are built upon. | |||
The Plasma library provides a scene/view (much like model/view) approach to presenting a user interface. Widgets sit on a canvas (the "Corona", a QGraphicsScene subclass), grouped into Containments. Data is obtained via DataEngines and Runners. The entire scene is designed to be viewed in a flexible manner, including zooming and resolution independence. | The Plasma library provides a scene/view (much like model/view) | ||
approach to presenting a user interface. | |||
Widgets sit on a canvas (the "Corona", a QGraphicsScene subclass), | |||
grouped into Containments. | |||
Data is obtained via DataEngines and Runners. | |||
The entire scene is designed to be viewed in a flexible manner, | |||
including zooming and resolution independence. | |||
Plasma also provides many standardized services such as artwork, presentation and script management, and creating add-ons for a Plasma application quite easy. | Plasma also provides many standardized services | ||
such as artwork, presentation and script management, | |||
and creating add-ons for a Plasma application quite easy. | |||
The goal of Plasma is to provide a flexible, re-targetable, scriptable and highly portable, and componentized interface to the user. | The goal of Plasma is to provide a flexible, re-targetable, | ||
scriptable and highly portable, and componentized interface to the user. | |||
==Widget== | |||
A widget is a single component on the canvas. Other common names that are analogous are "applet" or "gadget". Superkaramba Themes, Apple's Dashboard, Google Gadgets, Yahoo Widgets, Vista Sidebar Widgets, Opera Widgets are all examples of other widget systems (some of which are supported by Plasma via ScriptEngines as well). | A widget is a single component on the canvas. | ||
Other common names that are analogous are "applet" or "gadget". | |||
Superkaramba Themes, Apple's Dashboard, Google Gadgets, | |||
Yahoo Widgets, Vista Sidebar Widgets, Opera Widgets | |||
are all examples of other widget systems | |||
(some of which are supported by Plasma via ScriptEngines as well). | |||
==Plasmoid== | |||
A Plasmoid is the combination of files that go into creating a native Plasma widget. This includes: | A Plasmoid is the combination of files that go into creating a native Plasma widget. | ||
This includes: | |||
* metadata (e.g. .desktop files) | * metadata (e.g. .desktop files) | ||
* images (svg, png, etc) | * images (svg, png, etc) | ||
| Line 19: | Line 36: | ||
* ... | * ... | ||
==Applet== | |||
An applet is the code part of a Plasmoid, | An applet is the code part of a Plasmoid, | ||
technically because it provides a Plasma::Applet object. To users, this will | technically because it provides a Plasma::Applet object. | ||
be an implementation detail they are unlikely to see. | To users, this will be an implementation detail they are unlikely to see. | ||
==Corona== | |||
The Corona, a QGraphicsScene subclass, is the Plasma canvas. It contains all of the Containments that exist for the application, providing the "model" for the Views to use. | The Corona, a QGraphicsScene subclass, is the Plasma canvas. | ||
It contains all of the Containments that exist for the application, | |||
providing the "model" for the Views to use. | |||
It handles initiating loading and saving of Containments and Applets and other such canvas-global tasks. | It handles initiating loading and saving of Containments and Applets | ||
and other such canvas-global tasks. | |||
==Containment== | |||
A Containment is a top level grouping of widgets. Each Containment manages the layout and configuration data of its set of widgets independently from other Containments. | A Containment is a top level grouping of widgets. | ||
Each Containment manages the layout and configuration data | |||
of its set of widgets independently from other Containments. | |||
In the Plasma Desktop, for instance, each panel on screen is viewing a (panel) Containment, and each activity is a collection of one or more Containments as well (usually one per screen). | In the Plasma Desktop, for instance, | ||
each panel on screen is viewing a (panel) Containment, | |||
and each activity is a collection | |||
of one or more Containments as well | |||
(usually one per screen). | |||
==Data Engine== | |||
A DataEngine is a plugin that provides a ''visualization'' with a standard way to access a body of information. Each unit of data is called a "source", and source may be created on demand. Sources are updated either when the data changes (such as in response to a hotplug event for the devices DataEngine) or in a timed interval as requested by the visualization. | A DataEngine is a plugin that provides a ''visualization'' | ||
with a standard way to access a body of information. | |||
Each unit of data is called a "source", | |||
and source may be created on demand. | |||
Sources are updated either when the data changes | |||
(such as in response to a hotplug event for the devices DataEngine) | |||
or in a timed interval as requested by the visualization. | |||
The timings and memory management of the sources are handled by DataEngine, making implementation of DataEngines trivial. | The timings and memory management of the sources are handled by DataEngine, | ||
making implementation of DataEngines trivial. | |||
The sources themselves are organized into a list, and each source can have zero or more key/value pairs. The values are QVariants and therefore quite flexible. | The sources themselves are organized into a list, | ||
and each source can have zero or more key/value pairs. | |||
The values are QVariants and therefore quite flexible. | |||
DataEngines send information to visualizations via the dataUpdated(QString source, Plasma::Data data) slot that all visualizations must implement to receive updates. | DataEngines send information to visualizations | ||
via the dataUpdated(QString source, Plasma::Data data) slot | |||
that all visualizations must implement to receive updates. | |||
==Runner== | |||
A Runner is a plugin that provides possible matches to search queries. Runners are generally used and coordinated via Plasma::RunnerManager, which provides a multi-threaded runtime for collections of Runners. This sytem is used in KRunner, Kickoff and other places that need this kind of functionality. | A Runner is a plugin that provides possible matches to search queries. | ||
Runners are generally used and coordinated via Plasma::RunnerManager, | |||
which provides a multi-threaded runtime for collections of Runners. | |||
This sytem is used in KRunner, Kickoff | |||
and other places that need this kind of functionality. | |||
== More terminology == | |||
=== Workflow === | |||
Workflow is the sequence of actions a user performs to accomplish a task. A workflow involves applications, but can also lead the user across devices. | |||
Example: | |||
* Writing a report and sending it to your boss | |||
* Importing photos and reviewing them | |||
* Interacting friends (catching up on the social network, taking part) | |||
* Running into articles while working on the desktop, reading them on your tablet later | |||
* Downloading a movie on the laptop, watching it on the TV/Media Center | |||
=== Workspace === | |||
The workspace's purpose is to guide the user through their workflow, across applications. A workspace runs on a specific device, such as Desktop, tablet, etc, and forms part of workflows across devices. | |||
The workspace is a generic term for all the software component intended to provide the final UX for the global work environment, the minimal "fixed" running user interface that manages documents, applications (opening, closing) and global system properties such as notifications or attached hardware devices. | |||
Examples: | |||
* KDE Plasma Desktop | |||
* KDE Plasma Mobile | |||
(KDE is used as umbrella brand in this context, standing for "created by the KDE community") | |||
=== Shell === | |||
The shell, technically speaking, is the binary that will load and display the UI parts of the "Workspace". It doesn't provide its own UI, it may be tied to a particular form-factor. | |||
Examples (these refer *only* to binary names): | |||
* plasma-desktop | |||
* plasma-mobile | |||
==== Current Implementation ==== | |||
The term shell does not include Plasmoids loaded into it, it provides the implementation of the Corona and defines how the views are bound to it. These views hold containment, which then loads applets. The particular shell and the final UX are only tied in part. | |||
=== Activities === | |||
Latest revision as of 14:34, 12 February 2023
Plasma
Plasma refers to the framework upon which the various Plasma workspaces, Plasma and KRunner plugins, etc. are built upon.
The Plasma library provides a scene/view (much like model/view) approach to presenting a user interface. Widgets sit on a canvas (the "Corona", a QGraphicsScene subclass), grouped into Containments. Data is obtained via DataEngines and Runners. The entire scene is designed to be viewed in a flexible manner, including zooming and resolution independence.
Plasma also provides many standardized services such as artwork, presentation and script management, and creating add-ons for a Plasma application quite easy.
The goal of Plasma is to provide a flexible, re-targetable, scriptable and highly portable, and componentized interface to the user.
Widget
A widget is a single component on the canvas. Other common names that are analogous are "applet" or "gadget". Superkaramba Themes, Apple's Dashboard, Google Gadgets, Yahoo Widgets, Vista Sidebar Widgets, Opera Widgets are all examples of other widget systems (some of which are supported by Plasma via ScriptEngines as well).
Plasmoid
A Plasmoid is the combination of files that go into creating a native Plasma widget. This includes:
- metadata (e.g. .desktop files)
- images (svg, png, etc)
- configuration definitions (KConfigXT)
- code (C++, ECMA Script, HTML+JavaScript, Python, ..)
- ...
Applet
An applet is the code part of a Plasmoid, technically because it provides a Plasma::Applet object. To users, this will be an implementation detail they are unlikely to see.
Corona
The Corona, a QGraphicsScene subclass, is the Plasma canvas. It contains all of the Containments that exist for the application, providing the "model" for the Views to use.
It handles initiating loading and saving of Containments and Applets and other such canvas-global tasks.
Containment
A Containment is a top level grouping of widgets. Each Containment manages the layout and configuration data of its set of widgets independently from other Containments.
In the Plasma Desktop, for instance, each panel on screen is viewing a (panel) Containment, and each activity is a collection of one or more Containments as well (usually one per screen).
Data Engine
A DataEngine is a plugin that provides a visualization with a standard way to access a body of information. Each unit of data is called a "source", and source may be created on demand. Sources are updated either when the data changes (such as in response to a hotplug event for the devices DataEngine) or in a timed interval as requested by the visualization.
The timings and memory management of the sources are handled by DataEngine, making implementation of DataEngines trivial.
The sources themselves are organized into a list, and each source can have zero or more key/value pairs. The values are QVariants and therefore quite flexible.
DataEngines send information to visualizations via the dataUpdated(QString source, Plasma::Data data) slot that all visualizations must implement to receive updates.
Runner
A Runner is a plugin that provides possible matches to search queries. Runners are generally used and coordinated via Plasma::RunnerManager, which provides a multi-threaded runtime for collections of Runners. This sytem is used in KRunner, Kickoff and other places that need this kind of functionality.
More terminology
Workflow
Workflow is the sequence of actions a user performs to accomplish a task. A workflow involves applications, but can also lead the user across devices.
Example:
- Writing a report and sending it to your boss
- Importing photos and reviewing them
- Interacting friends (catching up on the social network, taking part)
- Running into articles while working on the desktop, reading them on your tablet later
- Downloading a movie on the laptop, watching it on the TV/Media Center
Workspace
The workspace's purpose is to guide the user through their workflow, across applications. A workspace runs on a specific device, such as Desktop, tablet, etc, and forms part of workflows across devices. The workspace is a generic term for all the software component intended to provide the final UX for the global work environment, the minimal "fixed" running user interface that manages documents, applications (opening, closing) and global system properties such as notifications or attached hardware devices.
Examples:
- KDE Plasma Desktop
- KDE Plasma Mobile
(KDE is used as umbrella brand in this context, standing for "created by the KDE community")
Shell
The shell, technically speaking, is the binary that will load and display the UI parts of the "Workspace". It doesn't provide its own UI, it may be tied to a particular form-factor.
Examples (these refer *only* to binary names):
- plasma-desktop
- plasma-mobile
Current Implementation
The term shell does not include Plasmoids loaded into it, it provides the implementation of the Corona and defines how the views are bound to it. These views hold containment, which then loads applets. The particular shell and the final UX are only tied in part.