matplotlib-devel Mailing List for matplotlib

In article <201...@me...>,
 mark <ma...@me...> wrote:
> Many thanks for the feedback.
> 
> So ,my first cut was to segregate the user guide by topic. Below is
> the summary I had in mind for an Introduction for New Users.
> 
> Hopefully this gives a flavour of what I have in mind.
> 
> I will attempt to put this into practice and post again when I have a
> user guide coded that might work in my view.
> 
> mark
> 
> 
> Introducing Plotting with Matplotlib
> 
> Pyplot tutorial
> Controlling line properties
> Working with multiple figures and axes
> Working with text
> Interactive navigation
> Navigation Keyboard Shortcuts
> Working with text
> Text introduction
> Basic text commands
> Text properties and layout
> Writing mathematical expressions
> Text rendering With LaTeX
> Annotating text
...
On the whole this looks good to me. I so have a few comments, however:
- Would you be willing to include a section on using the class API? (I'm 
assuming the above is all based on using pyplot?). I find there is a 
huge gap between pyplot and the class API, and the documentation I've 
found does little to bridge that gap.
- You have "Working with text" (including "annotating text") early on, 
then "Legend guide" and "Annotating Axes" much later on. I wish these 
were all together, as axes (values and labels), plot titles and legends 
are arguably the main use cases for text in plots. Perhaps it would 
suffice to have "Working with text" give a brief overview of how to do 
each of these things, with pointers to the other sections for details. 
An alternative is subsections within Working with text.
- In a similar vein: I'm surprised GridSpec comes before legends and 
annotating axes.
- Please consider a section on 3-d plots.
- Please consider a section on animation.
-- Russell

In article <524...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:
> On 10/02/2013 01:34 PM, Russell E. Owen wrote:
> > In article <524...@st...>,
> > Michael Droettboom <md...@st...>
> > wrote:
> >
> >> I haven't heard of this issue before.
> >>
> >> fc-list comes from the fontconfig project. It is used to get a list of
> >> all of the fonts installed on the system. It sounds like there is some
> >> bug there -- the usual culprit is that there is a slightly non-standard
> >> font installed on the system and fontconfig has a hard time parsing it.
> >> You could try updating fc-list (it's in all the major package managers).
> >>
> >> As for a workaround from our end, we could try to set a timeout on
> >> fc-list and just skip it if it takes too long. We can't rely on it
> >> being there on a Mac at all, so already we gracefully degrade to a less
> >> thorough search for fonts when fc-list can't be found.
> > Thanks for the advice. A defective font is an interesting possibility.
> >
> > I was wrong it's new in 1.3.0; turns out it's seen in much older
> > versions of my application (back to using mpl 1.0.0), but apparently on
> > few machines.
> >
> > The issue showed up when I added some fancy animated strip charts to my
> > application (which may be a coincidence), not when I upgraded mpl.
> >
> > I'm surprised the timeout on fc-list isn't working.
> 
> We don't currently do a timeout -- we make a blocking call to fc-list. 
> I was only suggesting it as a possible fix for this problem.
Sorry. I read too hastily. If it's not too hard to code a time limit, it 
sounds like a good idea.
> > Maybe something else
> > is also using fc-list, but the fix is to add an ~/.matplotlib dir, which
> > suggests it's an mpl issue.
> 
> When you copy over the .matplotlib dir, you copy over the font cache. 
> When matplotlib finds a font cache, it doesn't need to generate a list 
> of fonts, so thus doesn't need to call fc-list. But copying font caches 
> from one machine to another is unlikely to work (the set of fonts and 
> their locations is quite likely different). Worse yet, if matplotlib 
> attempts to look up a font and finds that it isn't where the cache says 
> it is, it regenerates the cache again, and thus you could get this 
> hanging anyway.
Thank you for that warning.
As a followup: one of the two computers had 3 copies of fc-list (one 
from darwinports, one in /usr/local/bin and the on provided with Apple's 
X11). Making sure Apple's version ran seems to have cleared up the 
problem, based on one test. So we may have a fix.
I really appreciate the help.
-- Russell

Using git blame, I can see that the AxisMenu class was last touched by John
Hunter back in 2004, during a massive restructuring of the code-base. It
looks like at that time, there were only 3 interactive backends: Gtk, Wx
and TkAgg. Maybe someone with a much longer history than I could chime in
on the purpose of this class.

Hi
All around the documentation, there are plenty of places where the
signature of class variables is displayed straight and without any
formating.
For example
http://matplotlib.org/api/backend_bases_api.html?highlight=toolitems#matplotlib.backend_bases.NavigationToolbar2.toolitems
Is it possible to override this signature?
If I'm not wrong the autodoc_docstring_signature (sphinx
configuration) only works on callables
Thanks
Federico
-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
-- Antonio Alducin --

Hello
I am preparing the Tkinter implementation of my MultiFigureManager
In backend_tkagg there is AxisMenu
Looking throught all the matplotlib code I do not see any place where
this is used, not even an example
Is this something that we want to keep around? does somebody use it?
Just as a reminder to get feedback on the multifigure-manager
Compare: https://github.com/fariza/matplotlib/compare/tabbed-gtk3-figuremanager
PR: https://github.com/matplotlib/matplotlib/pull/2465
Thanks
Federico
-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
-- Antonio Alducin --