← Back to team overview

gtg-contributors team mailing list archive

Re: Plugin API broken. How can I help?

 

Marko,

  Some further information for #1: see Lionel's comment at
https://code.launchpad.net/~gtg-contributors/gtg/code-layout/+merge/26624 , which does most of this work for you!

For #2 and #3, the current architecture has three key classes:
 * PluginAPI(core/plugins/api.py)
 * Plugin (core/plugins/engine.py)
 * PluginEngine (core/plugins/engine.py)

  One PluginEngine is created by the ViewManager class that runs the GTK
UI. The engine, in turn, creates many Plugins, and each one has a
Plugin.instance attribute which is an instance of the object described
in the plugin's source file.

  Each plugin is a class that must define certain methods (activate,
deactivate, onTaskOpened, etc.), but it doesn't inherit from anything
(see e.g. plugins/helloworld/helloworld.py). Activating all plugins is
achieved by iterating over every Plugin.instance that the PluginEngine
knows of, and calling activate() on each; similarly with other actions.

  The TaskEditor and ViewManager (but not the TaskBrowser) have
attributes that are instances of PluginAPI. These are passed to plugins
when certain methods are called.

Some of my thoughts on all this:
      * Individual plugins should inherit from a common class. This lets
        us provide more functionality to plugin authors, and also
        enforce the presence of certain methods by providing defaults.
        If we use "Plugin", then the current purpose of that task (a
        wrapper around a Plugin to make it useful for the PluginAPI)
        might no longer be necessary
      * Mass actions on plugins (activate, deactivate, check
        dependencies) can be handled by signals. Luca has already used
        signals for task syncing with a big performance boost, so I
        think this is a good model to follow.
      * There should be child classes for PluginAPI according to which
        "thing" is being exposed; e.g. EditorPluginAPI,
        BrowserPluginAPI. The TaskEditor and TaskBrowser should inherit
        from these classes. PluginAPI has functions now like
        is_browser(), is_editor(); these shouldn't be necessary.

On Tue, 2010-06-08 at 09:58 +0200, Lionel Dricot wrote:
> Hi Marko,
> 
> This is one big stuffs that requires lot of coding and architecture.
> 
> Paul is working on a core/UI separation as part of his Summer of Code. We
> currently believe that plugins will only affects the UI part. So, you have
> to concentrate on this.
> 
> 1) List the plugins that will stay. Some will diappears (Evolution, RTM),
> others should become a core-feature (like the task remover). Concentrate on
> important plugins.
> 
> 2) By reading the code of those plugins, you should make a list of
> features that are needed by those plugins. Write your perfect API. Also,
> any idea on how to improve plugin handling is warmly welcome.
> 
> 3) Then, we have to write that API and write support for that API in the
> GUI code. It's not that hard as most of it is already there. (for exemple,
> everything in the Task Editor should remains the same).
> 
> 4) Finally, we have to rewrite the plugins according to that API.
> 
> 
> Yep, that's big but every little step would be a great help. I can support
> you and answer your questions. If you achieve all of that, it would make
> you a major conntributor with a nearly complete understanding of the code
> (I will help you and write that with you, of course. We also might seek
> Paul's help) ;-)  But I would understand that it's huge. So right now, 1)
> and 2) are already a great great contribution.
> 
> 
> Lionel
> 
> On Tue, 8 Jun 2010 00:52:34 +0400, Marko Kevac <marko@xxxxxxxxx> wrote:
> > Hi.
> > 
> > https://bugs.launchpad.net/gtg/+bug/529520
> > 
> > What is status on this? How can I help?

Cheers,
-- 
Paul Kishimoto
MASc candidate (2010), Flight Systems & Control Group
University of Toronto Institute for Aerospace Studies (UTIAS)

http://paul.kishimoto.name — +19053029315

Attachment: signature.asc
Description: This is a digitally signed message part


References