Projects/Plasma/Vocabulary: Difference between revisions
(→Corona: adding something that made it click for me, may not be obvious) |
No edit summary |
||
(2 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
These shiny parts of KDE are star themed. Shiny! | |||
====Plasma==== | ====Plasma==== | ||
Plasma refers to two things: the Plasma library and the Plasma workspace. The workspace is the default desktop shell for KDE4, and the library is what drives it. | Plasma refers to two things: the Plasma library and the Plasma workspace. The workspace is the default desktop shell for KDE4, and the library is what drives it. | ||
Line 8: | Line 10: | ||
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. | ||
(In stars, plasma is`highly ionized gas, and it is associated with brilliant and efficient light. ) | |||
====Widget==== | ====Widget==== | ||
Line 19: | Line 23: | ||
* code (C++, ECMA Script, HTML+JavaScript, Python, ..) | * code (C++, ECMA Script, HTML+JavaScript, Python, ..) | ||
* ... | * ... | ||
( a cute name that sounds singluar, ball of plasma-- what the outer atmosphere of stars are made of) | |||
====Applet==== | ====Applet==== |
Latest revision as of 09:39, 14 July 2012
These shiny parts of KDE are star themed. Shiny!
Plasma
Plasma refers to two things: the Plasma library and the Plasma workspace. The workspace is the default desktop shell for KDE4, and the library is what drives it.
The Plasma library is generally the more interesting meaning of the word, as it provides a scene/view (much like model/view) approach to presenting a user interface. Widgets sit on the Corona canvas, 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.
(In stars, plasma is`highly ionized gas, and it is associated with brilliant and efficient light. )
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 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, ..)
- ...
( a cute name that sounds singluar, ball of plasma-- what the outer atmosphere of stars are made of)
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 probably never 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.
A corona is the outer part of a star. It's where the plasmoids live! =) There is one of these running in your KDE.
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 panel is a type of containment)
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.