GEPS 005: Enhanced Plugin Interface

From Gramps
Revision as of 23:22, 26 December 2012 by Patsyblefebre (talk | contribs) (Discussion: http://gramps.1791082.n4.nabble.com/Report-vs-ReportDialog-question-td1796820.html)
Jump to: navigation, search

Proposed changes for enhancing GRAMPS by updating the plugin interface to:

  1. be more flexible for future changes
  2. be more consistent across different types of plugins
  3. be more abstract

Motivation

The current plugin architecture is quite nice, and allows many different types of features to be added by users, or by developers. However, it needs to be updated so that it can support all of the different types of current and future plugins.

Details

There are a fixed number of parameters that one can use in defining each plugin type. Some plugins have had to be adapted to handle additional needs (like user interactions via a GUI). There is a middle layer of code that connects the plugin code with the plugin type. In this code there are places where the args get passed around like (item[0], item[1], item[3], item[10]) depending on the plugin type. In addition, some plugins have to go all the way down to the graphics interface (gtk).

Plan:

  1. Refactor the MenuOptions [under review]
  2. Add needed MenuOptions to cover all reports
  3. Update all of the reports to use abstract options ("menu" options) (see discussion here http://gramps.1791082.n4.nabble.com/RFC-Improving-report-options-td1796129.html)
  4. Generalize the report dialogs and remove the need for a report plugin to ever need to define or customize a dialog.
  5. Rethink each plugin type (report, graph, tool, etc) to be a well-defined API
  6. Move each plugin registration and handler from its current specific register_TYPE() to generic register(type=TYPE)

Third-Party Plugins

  1. Use the new two-file plugin format (.py + .gpr.py) together in a tgz file
  2. Possible directory-based format
  3. External SVN (http://sourceforge.net/projects/gramps-addons/)
  4. Plugin manager
  5. Need local translations
  6. Would be nice to incorporate an image of addon for browsing, and possible use in tool/report window.
  7. Need URL for documentation/updates
  8. Version number support for out-dated plugins

Notes

This section notes some of the details of how the current system works.

  1. Each plugin calls a register_TYPE() function.
  2. src/PluginUtils/_PluginMgr.py defines those functions
  3. src/ViewManager.py defines the callback for the menu, which calls:
    1. ReportBase.report(dbstate, uistate, dbstate.get_active_person(),lst[0], lst[1], lst[2], lst[3], lst[4], lst[5])
      1. report() function defined in src/ReportBase/_ReportDialog.py
      2. which actually runs class from class Report
      3. src/ReportBase/_ReportDialog.py ReportDialog is the window
    2. Tool.gui_tool(dbstate, uistate, lst[0], lst[1], lst[2], lst[3], lst[4], dbstate.db.request_rebuild)
      1. gui_tool() function defined in /src/PluginUtils/_Tool.py
      2. which actually runs class from class PluginUtils.PluginWindows.ToolManagedWindowBatch

Discussion

This proposal is discussed here:

If you have ideas, comments, or questions, please note them here.

As a first step, GEPS 014: Plugin registration and management is being implemented.