gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

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 ;-)


Lionel