Development/Tutorials/Plasma/ShellDesign - Revision history

Neverendingo: Text replace - "" to ""

2011-06-29T20:54:31Z

Text replace - "</code>" to "</syntaxhighlight>"

Neverendingo: Text replace - "`" to ""`


2011-06-29T20:28:23Z
Text replace - "<code cppqt>" to "<syntaxhighlight lang="cpp-qt">"

				
				
				
				
			
			← Older revision
			Revision as of 20:28, 29 June 2011
			
Line 81:
Line 81:
  By implementing these two methods for each plugin type of interest, shells can provide access to internal objects very easily. An example for DataEngines might look like this:   By implementing these two methods for each plugin type of interest, shells can provide access to internal objects very easily. An example for DataEngines might look like this:
    
− <code cppqt> + <syntaxhighlight lang="cpp-qt">
  KPluginInfo::List MyPluginLoader::internalDataEngineInfo() const   KPluginInfo::List MyPluginLoader::internalDataEngineInfo() const
  {   {
Line 211:
Line 211:
  Corona contains a set of protected methods which can be used to map animation types. This allows shells to customize what, for instance, the "AppearAnimation" actually means. Since different shells often have different needs when it comes to stock animations provided to Plasma components via Plasma::Animator, this is a way to accomplish that. So, for instance, a shell might do:   Corona contains a set of protected methods which can be used to map animation types. This allows shells to customize what, for instance, the "AppearAnimation" actually means. Since different shells often have different needs when it comes to stock animations provided to Plasma components via Plasma::Animator, this is a way to accomplish that. So, for instance, a shell might do:
    
− <code cppqt> + <syntaxhighlight lang="cpp-qt">
  mapAnimation(Plasma::Animator::AppearAnimation, Plasma::Animator::ZoomAnimation);   mapAnimation(Plasma::Animator::AppearAnimation, Plasma::Animator::ZoomAnimation);
  mapAnimation(Plasma::Animator::DisappearAnimation, Plasma::Animator::ZoomAnimation);   mapAnimation(Plasma::Animator::DisappearAnimation, Plasma::Animator::ZoomAnimation);



Sreich: grammar; added some important details
2010-12-16T03:05:32Z
grammar; added some important details

				
				
				
				
			
			← Older revision
			Revision as of 03:05, 16 December 2010
			
Line 89:
Line 89:
  Plasma::DataEngine *MyPluginLoader::internalLoadDataEngine(const QString &name)   Plasma::DataEngine *MyPluginLoader::internalLoadDataEngine(const QString &name)
  {   {
−      if (name == "SomeInternalEngine") { +      if (name == "org.kde.myapp.SomeInternalEngine") {
           return new InternalDataEngine();            return new InternalDataEngine();
       }        }
Line 96:
Line 96:
  }   }
  </code>   </code>
  + 
  + Note that the "org.kde.myapp" prefix is now the recommended way of naming plugins, this way it is not possible for any conflictions to come about.
    
  === Bringing It All Together ===   === Bringing It All Together ===
Line 153:
Line 155:
    
  It is advised (but not required) all the toolbox actions managed by the Containment are also part of the containment action set described above.   It is advised (but not required) all the toolbox actions managed by the Containment are also part of the containment action set described above.
  + 
  + If you would like to remove any actions, you would have to know their name, call delete on QAction* action(QString). Examples of names are "zoom in", "zoom out", "add widgets", "configure" (for the settings page), "unlock widgets", "unlock desktop" (the latter is a bit of a misnomer, and refers to the "Leave..."/shutdown action.
  + 
  + You can just grep for some occurrences of these to lead you to where you want, if you need more.
    
  === Add Widgets Interface ===   === Add Widgets Interface ===
Line 194:
Line 200:
  The plasma shell can control the security aspects of remote widgets, combined with a system wide config file (/etc/plasma-remotewidgets.conf) containing rules that can allow/disallow certain machines access to certain published widgets/services/engines. As a plasma shell you've got the following options:   The plasma shell can control the security aspects of remote widgets, combined with a system wide config file (/etc/plasma-remotewidgets.conf) containing rules that can allow/disallow certain machines access to certain published widgets/services/engines. As a plasma shell you've got the following options:
    
− * Use one of the sensible presets in which case you don't have to case about security. The only thing you'll need to do is set the desired behavior using AuthorizationManager::self()->setAuthorizationPolicy(). This will set the AuthorizationInterface implementation to one of the ones built in into libplasma. Do note that even when you whish to use the default policy (DenyAll), you should still call this function, since that automatically locks this value so a potential malicious plasma plugin can't change this to serve it's own evil desires. + * Use one of the sensible presets in which case you don't have to care about security. The only thing you'll need to do is set the desired behavior using AuthorizationManager::self()->setAuthorizationPolicy(). This will set the AuthorizationInterface implementation to one of the ones built in into libplasma. Do note that even when you whish to use the default policy (DenyAll), you should still call this function, since that automatically locks this value so a potential malicious plasma plugin can't change this to serve it's own evil desires.
  * Supply your own behavior by implementing AuthorizationInterface, set authorizationPolicy to custom, and use AuthorizationManager::self()->setAuthorizationInterface() to your own implementation.   * Supply your own behavior by implementing AuthorizationInterface, set authorizationPolicy to custom, and use AuthorizationManager::self()->setAuthorizationInterface() to your own implementation.
    





Nogden: reimplementation -> implementation for consistency.
2010-09-14T15:55:23Z
reimplementation -> implementation for consistency.

				
				
				
				
			
			← Older revision
			Revision as of 15:55, 14 September 2010
			
Line 57:
Line 57:
  * ''CustomPanelContainment'': for custom panels: won't have applet handles and the Corona won't assign a ToolBox by default, however it is possible to assign one to the containment implementation.   * ''CustomPanelContainment'': for custom panels: won't have applet handles and the Corona won't assign a ToolBox by default, however it is possible to assign one to the containment implementation.
    
− A Containment reimplementation manages the way the applets are laid out inside it, so it will have to react to new applets being added or removed into the containment, by connecting to the ''appletAdded(Plasma::Applet *applet)'' and ''appletRemoved(Plasma::Applet *applet)'' signals. + A Containment implementation manages the way the applets are laid out inside it, so it will have to react to new applets being added or removed into the containment, by connecting to the ''appletAdded(Plasma::Applet *applet)'' and ''appletRemoved(Plasma::Applet *applet)'' signals.
    
  If the applets in the containment can grow in any direction they want, the containment will have a 'Plasma::Planar'' FormFactor, otherwise will be ''Plasma::Horizontal'' if they can grow only horizontally and ''Plasma::Vertical'' if they can grow only vertically.   If the applets in the containment can grow in any direction they want, the containment will have a 'Plasma::Planar'' FormFactor, otherwise will be ''Plasma::Horizontal'' if they can grow only horizontally and ''Plasma::Vertical'' if they can grow only vertically.





Nogden: Corrected spelling and grammar.
2010-09-14T15:53:45Z
Corrected spelling and grammar.

				
				
				
				
			
			← Older revision
			Revision as of 15:53, 14 September 2010
			
Line 51:
Line 51:
    
  === Custom Containments ===   === Custom Containments ===
− Containments implementations can have several types: + Containment implementations can have several types:
− * ''DesktopContainment'': dafault desktop containment, it will have standard applet handles and the Corona will assign a ToolBox to it. + * ''DesktopContainment'': default desktop containment, will have standard applet handles and the Corona will assign a ToolBox to it.
  * ''PanelContainment'' : default panel containment, won't have applet handles and the Corona will assign a ToolBox to it.   * ''PanelContainment'' : default panel containment, won't have applet handles and the Corona will assign a ToolBox to it.
− * ''CustomContainment'': won't have applet handles and the Corona won't assign a ToolBox by default (it's possible to assign one into the containment implementation tough) + * ''CustomContainment'': won't have applet handles and the Corona won't assign a ToolBox by default, however it is possible to assign one to the containment implementation.
− * ''CustomPanelContainment'': for custom panels: won't have applet handles and the Corona won't assign a ToolBox by default (it's possible to assign one into the containment implementation tough) + * ''CustomPanelContainment'': for custom panels: won't have applet handles and the Corona won't assign a ToolBox by default, however it is possible to assign one to the containment implementation.
    
  A Containment reimplementation manages the way the applets are laid out inside it, so it will have to react to new applets being added or removed into the containment, by connecting to the ''appletAdded(Plasma::Applet *applet)'' and ''appletRemoved(Plasma::Applet *applet)'' signals.   A Containment reimplementation manages the way the applets are laid out inside it, so it will have to react to new applets being added or removed into the containment, by connecting to the ''appletAdded(Plasma::Applet *applet)'' and ''appletRemoved(Plasma::Applet *applet)'' signals.
Line 61:
Line 61:
  If the applets in the containment can grow in any direction they want, the containment will have a 'Plasma::Planar'' FormFactor, otherwise will be ''Plasma::Horizontal'' if they can grow only horizontally and ''Plasma::Vertical'' if they can grow only vertically.   If the applets in the containment can grow in any direction they want, the containment will have a 'Plasma::Planar'' FormFactor, otherwise will be ''Plasma::Horizontal'' if they can grow only horizontally and ''Plasma::Vertical'' if they can grow only vertically.
    
− A typical use case is to set a Planar FormFactor when the Location is ''Plasma::Floating'', ''Plasma::Desktop'' or ''Plasma::FullScreen''. While will be Horizontal for a ''BottomEdge'' or ''TopEdge'' Location and Vertical for a ''LeftEdge'' or ''RightEdge'' Location. + A typical use case is to set a Planar FormFactor when the Location is ''Plasma::Floating'', ''Plasma::Desktop'' or ''Plasma::FullScreen''. Which will be Horizontal for a ''BottomEdge'' or ''TopEdge'' Location and Vertical for a ''LeftEdge'' or ''RightEdge'' Location.
    
  === PluginLoader ===   === PluginLoader ===



Nogden: Corrected missing pluralisation.
2010-09-14T15:47:33Z
Corrected missing pluralisation.

				
				
				
				
			
			← Older revision
			Revision as of 15:47, 14 September 2010
			
Line 26:
Line 26:
    
  === The Base Canvas: Corona ===   === The Base Canvas: Corona ===
− Corona is a subclass of QGraphicsScene, however it provide several additional facilities: + Corona is a subclass of QGraphicsScene, however it provides several additional facilities:
    
  * There is one and only one Corona instance per application   * There is one and only one Corona instance per application



Jdalton: /* Containment Actions */
2010-08-17T17:18:38Z
‎Containment Actions

				
				
				
				
			
			← Older revision
			Revision as of 17:18, 17 August 2010
			
Line 152:
Line 152:
  Containment::addToolBoxAction(QAction *action) should be invoked.   Containment::addToolBoxAction(QAction *action) should be invoked.
    
− It is advised (but not required) all the toolbox actions managed byy the Containment are also part of the containment action set described above. + It is advised (but not required) all the toolbox actions managed by the Containment are also part of the containment action set described above.
    
  === Add Widgets Interface ===   === Add Widgets Interface ===



Jdalton: /* Views */
2010-08-17T01:58:31Z
‎Views

				
				
				
				
			
			← Older revision
			Revision as of 01:58, 17 August 2010
			
Line 47:
Line 47:
  * It will always have an 1:1 association with a Containment   * It will always have an 1:1 association with a Containment
  * Its sceneRect() will always be synchronized with its Containment geometry()   * Its sceneRect() will always be synchronized with its Containment geometry()
− * It has a ''screen'' and ''desktop'' property: a view will be associated to a phisical screen and a virtual desktop, and will be syncronized with the Containment. Not all reimplementations need to actually associate physical screens: for instance in an application dashboardthere won't be this physical->logic association of screens + * It has a ''screen'' and ''desktop'' property: a view will be associated to a physical screen and a virtual desktop, and will be synchronized with the Containment. Not all reimplementations need to actually associate physical screens: for instance in an application dashboard there won't be this physical->logic association of screens
  * It has its own configuration, of all values that don't depend on scene items, but from actual window geometry/properties (such as panel position, or showing the view on all virtual desktops)   * It has its own configuration, of all values that don't depend on scene items, but from actual window geometry/properties (such as panel position, or showing the view on all virtual desktops)
    



Aseigo: /* Scripting */
2010-08-11T07:18:34Z
‎Scripting

				
				
				
				
			
			← Older revision
			Revision as of 07:18, 11 August 2010
			
Line 223:
Line 223:
    
  === Scripting ===   === Scripting ===
  + 
  + Deployers and users of Plasma shells often find it more convenient, powerful and useful to interact with the shell using scripting. The recommended mechanism for doing so is to use Javascript via QtScript to offer a well defined set of shell-specific interaction API. This approach can be used in Corona::loadDefaultLayout() to create highly dynamic layouts without having to modify source code or manage complex default configuration files.
  + 
  + A comprehensive example of this is the [[KDE_System_Administration/PlasmaDesktopScripting|Plasma Shell Scripting]] shared by Plasma Desktop and Netbook, or the scripting provided as part of the Plasma KPart shell.



Aseigo: /* Animation Customization */
2010-08-11T07:15:14Z
‎Animation Customization

				
				
				
				
			
			← Older revision
			Revision as of 07:15, 11 August 2010
			
Line 202:
Line 202:
    
  === Animation Customization ===   === Animation Customization ===
  + 
  + Corona contains a set of protected methods which can be used to map animation types. This allows shells to customize what, for instance, the "AppearAnimation" actually means. Since different shells often have different needs when it comes to stock animations provided to Plasma components via Plasma::Animator, this is a way to accomplish that. So, for instance, a shell might do:
  + 
  + <code cppqt>
  + mapAnimation(Plasma::Animator::AppearAnimation, Plasma::Animator::ZoomAnimation);
  + mapAnimation(Plasma::Animator::DisappearAnimation, Plasma::Animator::ZoomAnimation);
  + </code>
  + 
  + Additionally, shells may install [[Development/Tutorials/Plasma/JavaScript/Animations|Javascript animations]] which are then accessible to any users of Plasma::Animator. These animations may also be mapped to standard animations such as AppearAnimation, allowing for a high degree of customization and even the addition of entirely new animation possibilities.
    
  == Configuration and Automation ==   == Configuration and Automation ==

@@ Line 95: / Line 95: @@
      return 0;
+}
-</code>
+</syntaxhighlight>
 Note that the "org.kde.myapp" prefix is now the recommended way of naming plugins, this way it is not possible for any conflictions to come about.
@@ Line 214: / Line 214: @@
 mapAnimation(Plasma::Animator::AppearAnimation, Plasma::Animator::ZoomAnimation);
 mapAnimation(Plasma::Animator::DisappearAnimation, Plasma::Animator::ZoomAnimation);
-</code>
+</syntaxhighlight>
 Additionally, shells may install [[Development/Tutorials/Plasma/JavaScript/Animations|Javascript animations]] which are then accessible to any users of Plasma::Animator. These animations may also be mapped to standard animations such as AppearAnimation, allowing for a high degree of customization and even the addition of entirely new animation possibilities.

← Older revision		Revision as of 07:18, 11 August 2010
Line 223:		Line 223:

	=== Scripting ===		=== Scripting ===
		+
		+	Deployers and users of Plasma shells often find it more convenient, powerful and useful to interact with the shell using scripting. The recommended mechanism for doing so is to use Javascript via QtScript to offer a well defined set of shell-specific interaction API. This approach can be used in Corona::loadDefaultLayout() to create highly dynamic layouts without having to modify source code or manage complex default configuration files.
		+
		+	A comprehensive example of this is the [[KDE_System_Administration/PlasmaDesktopScripting\|Plasma Shell Scripting]] shared by Plasma Desktop and Netbook, or the scripting provided as part of the Plasma KPart shell.

← Older revision		Revision as of 07:15, 11 August 2010
Line 202:		Line 202:

	=== Animation Customization ===		=== Animation Customization ===
		+
		+	Corona contains a set of protected methods which can be used to map animation types. This allows shells to customize what, for instance, the "AppearAnimation" actually means. Since different shells often have different needs when it comes to stock animations provided to Plasma components via Plasma::Animator, this is a way to accomplish that. So, for instance, a shell might do:
		+
		+	<code cppqt>
		+	mapAnimation(Plasma::Animator::AppearAnimation, Plasma::Animator::ZoomAnimation);
		+	mapAnimation(Plasma::Animator::DisappearAnimation, Plasma::Animator::ZoomAnimation);
		+	</code>
		+
		+	Additionally, shells may install [[Development/Tutorials/Plasma/JavaScript/Animations\|Javascript animations]] which are then accessible to any users of Plasma::Animator. These animations may also be mapped to standard animations such as AppearAnimation, allowing for a high degree of customization and even the addition of entirely new animation possibilities.

	== Configuration and Automation ==		== Configuration and Automation ==