Editor:Proposal:Plugin format

This article is currently only a proposal

The features or design guidelines described in this article are only a proposal made by one or some persons. It has not been reviewed and ratified by the core development team yet. Feel free to add your personal opinion about them or make counter proposals.

This article is outdated and needs to be reviewed!

The content of this article is outdated and should be treated as such. We cannot guarantee the accuracy of the information presented here.

See Editor:Plugin_format for the final version.

Plugin format enhancements

Purpose

Currently, the editor features a plugin system which allows to write small modules and integrate them into the editor core.

Unfortunately, the integration of such a plugin is yet some work in the editor core files. My vision for a enhancement of this issue would be to create a plugin format specification which allows plugin authors to write their module, throw it into the plugins dir and choose "enabled/disabled" in the editor client itself - without adding something to the editor core files.

So far this automatic integration is true for the menu bar of the editor - you just specify a name and a callback in your plugin, and the editor will add this automaticly in his menu.

The vision of this proposal:

• Projects using FIFE should be able to use FIFedit in every stage of development
• No project should be forced to fork FIFedit to e.g. be able to also place triggers on the maps
• FIFedit should have basic functionality (opening / saving maps, placing / deleting / moving instances etc.) and allow plugins to do more with the selected instances / loaded maps / whatever else you might need for map creation.

This is all about workflow: Why you should write and maintain a customized editor if this can be avoided. Or: Why should you switch to a custom tool to place triggers, setup npc inventories, add player starting points, add map exit points etc...

Plugins for FIFedit can e.g. write data to own fileformats (sqlite, xml, other custom binarys) and are easier to maintain then a full featured (customized) editor suite. Plus, if major changes are made in FIFE, only one application has to be updated, and all projects are in sync again. (without spending hours to update their homebrewn tools)

Features

The new plugin system should be able to:

• load plugins from clients/editor/plugins automaticly
• add the plugin to a list of available plugin
• activate / deactivate plugins
• provide an interface for the editor undo history to revert actions of a plugin

Plugin manager and saving enabled/disabled

• A plugin manager window should be created so the user can control which plugins are enabled
• All plugins should be disabled by default
• A list of enabled plugins should be saved whenever a plugin is enabled/disabled
• PluginManager should read this list when it is loaded and enable the appropriate plugins

Alternative 1: No fancy name yet

Interface

This is a draft for the new plugin system.

PluginManager

 class PluginManager
   
   void updatePluginList()
   list getPluginList()
   
   void enablePlugin(string plugin)
   void disablePlugin(string plugin)
   
   void loadPluginList()
   void savePluginList()

Plugin

Interface for plugins.

See:

• http://dev.mysql.com/doc/refman/5.1/en/plugin-api-general.html

 class Plugin
   void enable()
   void disable()
   
   bool isEnabled()
   
   string getName()
   string getAuthor()
   string getDescription()
   
   string getLicense()
   string getVersion()

Plugin example

Untested code.

 from plugin import Plugin
 from pychan import widgets, tools
 
 class MyPlugin(Plugin):
   def __init__(self):
     pass
   
   #--- Plugin interface methods ---#
   
   def enable(self, editor):
     self.gui = tools.loadXML("gui/myplugin.xml")
     
     showButton = self.gui.findChild(name="showButton")
     hideButton = self.gui.findChild(name="hideButton")
     showbutton.capture(self.showAllLayers)
     hideButton.capture(self.hideAllLayers)
    
   def disable(self, editor):
     showButton = self.gui.findChild(name="showButton")
     hideButton = self.gui.findChild(name="hideButton")
     showbutton.capture(None)
     hideButton.capture(None)
     
     self.gui = None
   
   def getName(self):
     return "My plugin"
  
   # [...]
   
   #--- Other methods ---#
   def showAllLayers(self, event):
     layers = self.editor.getEngine().getMap().getLayers()
     for layer in layers:
       layer.show()
   
   def hideAllLayers(self, event):
     layers = self.editor.getEngine().getMap().getLayers()
     for layer in layers:
       layer.hide()

Alternative 2: Event based

Additional features

• provide a "message" system which a plugin author can use to request editor attributes (e.g. to get the currently selected instance)
• provide a plugin template which can be used by the various FIFE projects to enable their favoured plugin environment

Additional ideas:

• provide basic plugins which can be used by new plugins (e.g.: basic_plugin_layers loads all layers, layertool uses basic_plugin_layers to make something with the data)

Code-Mockup

FIFedit uses this one to register Plugins on the menu bar:

Python:

# [..]

self.menu_items = { 'LayerTool' : self.toggle }

# [..]

This is just a name for the new button (used as caption and id (!)) and a callback packed into a dict. The installation is done via the plugin module each plugin inherits from.

My idea is to use this to also access / demand editor components which the plugin needs to work - e.g.:

Python:

# [..]

self.needed_attributes = [{ 'get_instance' : {

# which attr should go where

'_instance' : self.update,

# method which triggers callback

'mousePressed',

}

}]

# [..]

def update(self, instance):

""" the plugin receives an update from editor core """

if instance is not None:

print "Instance %s is selected" % (instance.getId())

The evaluation of the self.needed_attributes list should also be done via the plugin class, which hands them over to the editor core.

Of course, we need a hell of a list of possible attributes which might be interesting for plugin authors - or even better, make heavy use of introspection to allow full control over all aspects of the editor client.

Links

• Building a plugin architecture in C#