matplotlib-devel Mailing List for matplotlib

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

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:
>>>>>>"Steve" == Steve Chaplin <ste...@ya...> writes:
>>>>>> 
>>>>>>
>
> Steve> Perhaps the .matplotlibrc file could have lines like
> Steve> printcommand: None printcommand: '"lpr %s" % path' And if
> Steve> printcommand is not None an extra toolbar button is created
> Steve> 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.
>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
>

Paul Barrett wrote:
> OK, I've created a patch to work around the 'gv' problem for dense line plots. 
> Attached is a PS file created from this patch. Please test to see if it solves 
> your problem. If it does, I'll commit the patch to CVS. It worked for me on 'ggv'.
Works OK now with gv on Fedora Core 2.
Thanks,
f

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> Perhaps the .matplotlibrc file could have lines like
 Steve> printcommand: None printcommand: '"lpr %s" % path' And if
 Steve> printcommand is not None an extra toolbar button is created
 Steve> 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

John Hunter wrote:
>>>>>>"Paul" == Paul Barrett <ba...@st...> writes:
> 
> 
> Paul> OK, I've created a patch to work around the 'gv' problem for
> Paul> dense line plots. Attached is a PS file created from this
> Paul> patch. Please test to see if it solves your problem. If it
> Paul> does, I'll commit the patch to CVS. It worked for me on
> Paul> 'ggv'.
> 
> Works for me (also ggv) - what did you do, break up paths longer than
> a certain size into multiple paths? I need to do the same for agg to
> fix Jin-chung's bug.
Yes. Paths are divided into mutiple paths of 1000 points (except for the last 
path with can contain upto 1001 points to prevent the last point from being 
orphaned). This path size seemed like a reasonable number. I didn't do any 
tests to determine the optimum path size. From the way gv behaves on my Linux 
box, it appears that 5000 points may be the limit.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:
 Paul> OK, I've created a patch to work around the 'gv' problem for
 Paul> dense line plots. Attached is a PS file created from this
 Paul> patch. Please test to see if it solves your problem. If it
 Paul> does, I'll commit the patch to CVS. It worked for me on
 Paul> 'ggv'.
Works for me (also ggv) - what did you do, break up paths longer than
a certain size into multiple paths? I need to do the same for agg to
fix Jin-chung's bug.
JDH

Fernando Perez wrote:
> Paul Barrett wrote:
> 
>> I found a bug in the Y-axis scaling. See the attached PS file. The 
>> Y-axis scale should go from 0. to 2.0e-11 (in ergs/cm**2/s/Angstrom). 
>> Instead it is zeros. Anyone having experience with the scaling code 
>> want to fix this?
>>
>> For those interested, this is a section of the far ultraviolet 
>> spectrum of the variable star SS Cygni (SS Cyg for short) taken by 
>> NASA's Far Ultraviolet Spectroscopic Explorer (FUSE for short).
> 
> 
> Well, I actually tried to see it but gv (Fedora Core 2) chokes on the 
> file: CPU utilization goes to 100% after displaying the axes, labels, 
> and a tiny bit of the graph. I killed it after a while.
> 
> Are there known problems with the Postscript generated by matplotlib? 
> Can it produce EPS directly (better for publication)?
OK, I've created a patch to work around the 'gv' problem for dense line plots. 
Attached is a PS file created from this patch. Please test to see if it solves 
your problem. If it does, I'll commit the patch to CVS. It worked for me on 'ggv'.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218