toolbar buttons

Perhaps the .matplotlibrc file could have lines like

    > printcommand: None printcommand: '"lpr %s" % path' And if
    > printcommand is not None an extra toolbar button is created
    > which calls os.system(printcommand) to print the file.

This is a good idea, perhaps the rc param should be
savefig.printcommand. There was a post on the users list which
contained some help on how to print from wx on win32.

Anyone want to take the lead here?

JDH

What might be a cool extension on this idea, would be the ability to specify 'plugin' actions to add to the toolbar:

toolbar.buttons : (name, tooltip, image, function), (name, tooltip, image, function)

The difficulty would specifying which modules to load. One simple approach might be to have a directory called 'plugins', in which all modules automatically get loaded.

I think this would take about the same amount of code as hard-coding a single printer option in, and might allow more flexibility (easier to add/remove buttons, and easier to change what action they perform).

I wrote a quick patch (attached to the email) which allows for two new rc params:
plugins.directory : <directory>
    any file in this directory ending in '.py' is automatically imported
toolbars.buttons: (name, tooltip, image, function), ...
    a list of the tuples is created

I didn't edit any of the backend code yet, but it should be trivial (at least in the case of the gtk backend) to convert 'toolitems' to an array, and then "if matplotlib.rcParams['toolbar.buttons']: toolitems.extend(matplotlib.rcParams['toolbar.buttons'])"

Abe

John Hunter wrote:

patch (1.5 KB)

···

"Steve" == Steve Chaplin <stevech1097@...49...> writes:
           
   > Perhaps the .matplotlibrc file could have lines like
   > printcommand: None printcommand: '"lpr %s" % path' And if
   > printcommand is not None an extra toolbar button is created
   > which calls os.system(printcommand) to print the file.

This is a good idea, perhaps the rc param should be
savefig.printcommand. There was a post on the users list which
contained some help on how to print from wx on win32.

Anyone want to take the lead here?

JDH

-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
Cheap Ink Cartridges: printer ink, printer cartridge, printer cartridges, inkjet cartridge, ink jet cartridges, ink cartridges, ink cartridge, inkjet cartridges, epson ink cartridge, epson ink cartridges
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

Abraham Schneider wrote:

What might be a cool extension on this idea, would be the ability to specify 'plugin' actions to add to the toolbar:

toolbar.buttons : (name, tooltip, image, function), (name, tooltip, image, function)

The difficulty would specifying which modules to load. One simple approach might be to have a directory called 'plugins', in which all modules automatically get loaded.

+1

Note that this should be specifyable as a colon-separated search path where matplotlib can look for all available plugins. This allows users to extend their local installation with custom things which survive across system-wide upgrades.

I recently patched MayaVi to do exactly this with Filters and Modules (it's in the mayavi CVS already), and it's extremely useful.

In mayavi, any directory in the mayavi search path is scanned for a subdir called Filters/ and one called Modules/. Any .py file found there is added to the User submenu of Mayavi's main Filters and Modules menus. With this system, local user extensions become automatically available to the GUI. In scripts, they can be loaded with a prepended 'User.' string:

load_module('Glyphs') -> loads MayaVi's Glyphs module
load_module('User.Glyphs') -> loads a users's customized Glyphs module, without clashing with the system-wide one.

I think this approach is very useful, esp. because it allows research groups to have directories of common functionality useful to their projects, and individual users can still add their own particular Filters/Modules.

Best,

f