Hi. I realized that having plugins loaded from the
> __init__.py file could cause dependency problems,
> depending on what was being done in the plugin. So I
> moved the code to a separate file called 'plugins.py'
> (attached). This also allows you to decide whether you
> want to load the plugins in the first place. It's also a
> cleaner solution in general..
> It's pretty rough code hacked together during wait
> time. I also wrote a quick 'print button' plugin (also
> attached) for proof of concept. The plugin only works
> with GTK right now, but it checks the backend being used,
> so it should be fairly simple to hack the other
> GUI/platform backends to use it.
> I'm interested in what people think.. Even if it doesn't
> get included in the main source, it's easy enough to add
> in, that upgrades will no longer be a problem.
I tried out your code and have a few questions.
Your example only works on the current figure toolbar - it this
desirable, or would it be better to modify the default toolbar? Also,
how do you use it? After your figure is realized, do you call
>>> load_plugins(rcParams)
to get your buttons? That seems like it would be cumbersome to have
to do this with every figure....
And why does load_plugins take rcParams as an arg rather than work on
the rcParams default? Do you plan on keeping different params with a
different plugins directories?
I may not be understanding how your code is supposed to work, but I
was envisioning something a little different after reading your
original post. I thought something along the lines of the following
in rc
# format is Name, Tooltip, image basename, callback
plugins.dirs : /path/to/plugins1:/path/to/plugins2
toolbar.button : Home, Reset original view, home_icon, mybackend.home
toolbar.button : Back, Back to previous view, back_icon, mybackend.back
toolbar.button : Forward, Forward to next view, forward_icon, mybackend.forward
toolbar.button : Pan, Pan axes with left mouse, zoom with right, move_icon, mybackend.pan
toolbar.button : Zoom, Zoom to rectangle, zoom_to_rect, mybackend.zoom
toolbar.button : Print, Print to PS, print_icon, plugins.print_ps
The order of the toolbar.button calls would determine which buttons
were placed in the toolbar and in what order. mybackend would be a
special string that matplotlib would use to substitute in for the
current backend, and each backend would implement these functions.
plugins (in the example plugins.print_ps) is a python code dir
somewhere in the plugins.dirs search path. Thus the same code could
be used to both build the default toolbar and used to customize it
(remove buttons, change their order, add user buttons).
I used icon names without extensions above because the different
backends generally need icons of different types, and the backend
could be responsible for supplying the extension. GTK could also
detect special names like STOCK_PRINT and handle those.
One thing this setup doesn't provide for is the ability to easily
switch to different configurations in the middle of an interactive
session. Is this important?
Another design issue that comes to mind is how to handle communication
between buttons. In the current toolbar2 design, when the zoom to
rectangle button is pressed, the pan/zoom callbacks are disconnected
and vis-a-versa. Presumably a more sophisticated model would have to
be used to handle the connection and disconnection of multiple buttons
that want to listen in on press/motion events.
It would provide a nice framework for supporting user contributions,
eg measurement tools, other navigation tools, etc...
JDH