gtg-contributors team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

On Mon, Mar 01, 2010 at 12:07:07AM +0100, Lionel Dricot wrote:
> Le dimanche 28 f??vrier 2010 ?? 14:22 -0800, Bryce Harrington a ??crit :
> > On Sun, Feb 28, 2010 at 05:46:16PM +0100, Lionel Dricot wrote:
> > > The main problem is with the plugin API that I barely touched. Like
> > > everything in GTG (and I'm the most guilty about that here), it was done
> > > reversely : instead of having hooks everywhere in the code to ask if a
> > > plugin want to do something, we were doing stuffs reversly. For example,
> > > our plugin API was directly adding/removing stuffs in the UI by playing
> > > with the UI. Instead, the browser.py should ask the plugin API "Do you
> > > want to put a button there ?".
> > > 
> > > This is something I barely touched and I'm don't have huge motivation
> > > for that so any help from plugin writers is welcome.
> > 
> > Could you explain this in more detail?
> 
> 
> Well, I think that the whole plugin architecture should be rethought
> with a clear view of the layers involved in GTG. I will think a bit
> about it this week but if plugins specialists want to have a look at the
> current state, don't hesitate to ask.
> 
> What I have in mind is that each View, be it a browser, an editor or
> whatever you could imagine, will receive one PluginAPI object. This is
> more or less the case actually but was done in the browser itself and
> this is currently not pretty due do the fact that we have to give plenty
> of objects as parameters to the plugin API and the plugin API contains a
> lot of "if if else else" each time to know if the view is an editor or a
> browser (ideally, it should be viewer independant).
> 
> 
> As an example, we are currently giving the gtk.builder object to the API
> so, if a plugin want to add a button to the toolbar, we take the toolbar
> object in the API and add a button.
> 
> Ideally, it should be done reversely : the viewer should ask the
> PluginAPI : are there buttons I should add ?
> 
> 
> I will try to be more clear tomorrow ;-)

So, to see if I understand this, a plugin should not be grabbing the
toolbar and putting menu items into it, but rather should be doing
something more like:

 1. Plugin instantiates.
 2. Plugin registers itself via the plugin api:
    - name: 'foobar'
    - hooks-into: ('plugin-menu', 'browser-context-menu', 'editor-toolbar')
 3. Task Browser asks plugin api for list of registered items to go 
    into 'plugin-menu', and updates menus
 4. Task Editor does likewise for 'editor-toolbar'
 5. Ditto for any other views

Or am I totally off base?

Bryce