← Back to team overview

gtg-contributors team mailing list archive

Re: Refactorisation finished !

 


>> 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?

Yep, that's it !


The rule of thumb to keep in mind is that modules should be independant.
Currently, if you modify the browser GLADE file, you can break all the
plugin API. This is not good. You should be able to modify a "viewer" or to
create a new one without caring about breaking stuffs. 

This involves, as you can guess, that we define some kind of communication
interface between the plugin API and the viewer.

This night, I had the idea of a simple dict. For example,
dict['main_toolbar_buttons'] would contain a list of buttons object that
should be added to the toolbar by any viewer that have a "main toolbar". It
could be the same for sidebar, bottom-pane, editor-toolbar,
editor-bottom-pane, etc…  I don't know if it's a good idea or not.

What do you think ?

PS : Paulo, if you are reading, I'm specially interested by your comments
due to your experience.


Lionel



References