Difference between revisions of "Platform Team/Sweets Distribution/Features/Plugins"

From Sugar Labs
Jump to navigation Jump to search
(Created page with "Plugins are pluggable Sugar Shell code. By design, plugins are not isolated from the rest of shell code and each over, thus, they are assumed to be setup by Sugar distributors...")
 
Line 1: Line 1:
Plugins are pluggable Sugar Shell code. By design, plugins are not isolated from the rest of shell code and each over, thus, they are assumed to be setup by Sugar distributors or experienced users.
+
Plugins are pluggable Sugar Shell code. By design, plugins are not isolated from the rest of shell code and each other, thus, they are assumed to be setup by Sugar distributors or experienced users.
  
Plugin ia a Python module placed to {{Code|/opt/sweets/sugar/src/jarabe/plugins/''PLUGIN_NAME''}} directory. To make plugin module useful, it should contain the following variables and functions:
+
A plugin is a Python module placed in a {{Code|/opt/sweets/sugar/src/jarabe/plugins/''PLUGIN_NAME''}} directory. To make a plugin module useful, it should contain the following variables and functions:
  
 
* {{Code|'''ORDER'''}}<br>Required. Variable with plugin order. Plugins with smaller {{Code|ORDER}} will be initiated and started earlier.
 
* {{Code|'''ORDER'''}}<br>Required. Variable with plugin order. Plugins with smaller {{Code|ORDER}} will be initiated and started earlier.
  
* {{Code|'''TITLE'''}}<br>Optional. This title will appear in ''Sweets Distribution'' Control Panel component to let user a chance to enable/disable plugin. If {{Code|TITLE}} is omitted, plugin will be enabled unconditionally.
+
* {{Code|'''TITLE'''}}<br>Optional. This title will appear in the ''Sweets Distribution'' Control Panel component in order to provide a user the opportunity to enable/disable the plugin. If {{Code|TITLE}} is omitted, the plugin will be enabled unconditionally.
  
* {{Code|'''init()'''}}<br>Required. Initialize the plugin. This function will be called before Shell initialization phase, so, it is possible to put here monkey patching code.
+
* {{Code|'''init()'''}}<br>Required. Initialize the plugin. This function will be called before the Shell initialization phase, so, it is possible to put [[Wikipedia:Monkey patch|monkey patching]] code here.
  
 
* {{Code|'''start()'''}}<br>Required. Start the plugin. Actual starting the plugin. This function will be called when Shell starts heavy code like Journal.
 
* {{Code|'''start()'''}}<br>Required. Start the plugin. Actual starting the plugin. This function will be called when Shell starts heavy code like Journal.
  
* {{Code|'''binding()'''}}<br>Optional. Posix shell commands to source before starting Sugar Shell. Function should return a list of strings. Resulting lines will be sourced before starting Sugar Shell process. Note that sourcing will happen before starting DBus session and after X session.
+
* {{Code|'''binding()'''}}<br>Optional. Posix shell commands to source before starting the Sugar Shell. Function should return a list of strings. Resulting lines will be sourced before starting the Sugar Shell process. Note that sourcing will happen before starting DBus session and after X session.
  
* {{Code|'''control_panel_section()'''}}<br>Optional. If it exists, it should return a widget to place as a sub-section to ''Sweets Distribution'' Control Panel section. Returnig widget should take care about reading/writing plugin configuration on its own and should assume applying configuration changes right after making them, i.e., without any apply buttons. The regular way to handle plugin configuration is using {{Code|Option}} class like below example code does.
+
* {{Code|'''control_panel_section()'''}}<br>Optional. If it exists, it should return a widget to place as a sub-section in the ''Sweets Distribution'' Control Panel section. The returning widget should take care of reading/writing the plugin configuration on its own, and should assume the application of configuration changes right after making them, i.e., without any apply buttons. The regular way to handle plugin configuration is using {{Code|Option}} class like the example code does below.
  
Use [http://git.sugarlabs.org/desktop/sugar-example-plugin example plugin] source as a template for new one.
+
Use [http://git.sugarlabs.org/desktop/sugar-example-plugin example plugin] source as a template for new ones.

Revision as of 20:53, 18 August 2012

Plugins are pluggable Sugar Shell code. By design, plugins are not isolated from the rest of shell code and each other, thus, they are assumed to be setup by Sugar distributors or experienced users.

A plugin is a Python module placed in a /opt/sweets/sugar/src/jarabe/plugins/PLUGIN_NAME directory. To make a plugin module useful, it should contain the following variables and functions:

  • ORDER
    Required. Variable with plugin order. Plugins with smaller ORDER will be initiated and started earlier.
  • TITLE
    Optional. This title will appear in the Sweets Distribution Control Panel component in order to provide a user the opportunity to enable/disable the plugin. If TITLE is omitted, the plugin will be enabled unconditionally.
  • init()
    Required. Initialize the plugin. This function will be called before the Shell initialization phase, so, it is possible to put monkey patching code here.
  • start()
    Required. Start the plugin. Actual starting the plugin. This function will be called when Shell starts heavy code like Journal.
  • binding()
    Optional. Posix shell commands to source before starting the Sugar Shell. Function should return a list of strings. Resulting lines will be sourced before starting the Sugar Shell process. Note that sourcing will happen before starting DBus session and after X session.
  • control_panel_section()
    Optional. If it exists, it should return a widget to place as a sub-section in the Sweets Distribution Control Panel section. The returning widget should take care of reading/writing the plugin configuration on its own, and should assume the application of configuration changes right after making them, i.e., without any apply buttons. The regular way to handle plugin configuration is using Option class like the example code does below.

Use example plugin source as a template for new ones.