matplotlib-devel Mailing List for matplotlib

A simpler fix would be:
 class FigureWindow(QtGui.QMainWindow):
 def __init__(self):
 super(FigureWindow, self).__init__()
 
 def closeEvent(self, event):
 super(FigureWindow, self).closeEvent(event)
 self.emit(QtCore.SIGNAL('destroyed()'))
and replacing QtGui.QMainWindow by FigureWindow in FigureManagerQT.
Pierre
Pierre Raybaut a écrit :
> Hi,
>
> Some Spyder users have reported a critical bug occuring with 
> matplotlib 0.99's Qt4 backend and PyQt4 v4.6 (e.g. in Ubuntu Karmic).
>
>
> Here is the traceback after calling 'plot([])', closing figure and 
> calling again 'plot([])' (e.g. in an IPython session with options 
> --pylab and --q4thread):
>
> Traceback (most recent call last):
> File "/home/rick/Temp/untitled0.py", line 9, in <module>
> show()
> File "/usr/lib/pymodules/python2.6/matplotlib/backends/backend_qt4.py",
> line 63, in show
> manager.window.show()
> RuntimeError: underlying C/C++ object has been deleted
>
>
> I found out that the 'destroyed()' signal (connected in class 
> FigureManagerQT) is never emitted when figure is closed.
> As a consequence, SIP is not very happy when trying to draw a deleted 
> object...
>
> I made the following changes to make it work:
>
> # New class to clarify code in FigureManagerQT
> class FigureWindow(QtGui.QMainWindow):
> def __init__(self, num, canvas, close_callback):
> super(FigureWindow, self).__init__()
> self.close_callback = close_callback
> self.setAttribute(QtCore.Qt.WA_DeleteOnClose)
> self.setWindowTitle("Figure %d" % num)
> image = os.path.join(matplotlib.rcParams['datapath'],
> 'images', 'matplotlib.png')
> self.setWindowIcon(QtGui.QIcon(image))
> self._destroying = False
> self.setCentralWidget(canvas)
> if matplotlib.is_interactive():
> self.show()
> def closeEvent(self, event):
> super(FigureWindow, self).closeEvent(event)
> self.close_callback()
>
> class FigureManagerQT( FigureManagerBase ):
> """
> Public attributes
>
> canvas : The FigureCanvas instance
> num : The Figure number
> toolbar : The qt.QToolBar
> window : The qt.QMainWindow
> """
>
> def __init__( self, canvas, num ):
> if DEBUG: print 'FigureManagerQT.%s' % fn_name()
> FigureManagerBase.__init__( self, canvas, num )
> self.canvas = canvas
>
> # Give the keyboard focus to the figure instead of the manager
> self.canvas.setFocusPolicy( QtCore.Qt.ClickFocus )
> self.canvas.setFocus()
>
> self.window = FigureWindow(num, self.canvas, self._widgetclosed)
> self.toolbar = self._get_toolbar(self.canvas, self.window)
> self.window.addToolBar(self.toolbar)
> QtCore.QObject.connect(self.toolbar, QtCore.SIGNAL("message"),
> self.window.statusBar().showMessage)
> # [...]
>
> And we may now remove the "QtCore.QObject.disconnect" for the no 
> longer existing signal 'destroyed()' in method 'FigureManagerQT.
> destroy'.
>
> HTH
>
> Cheers,
> Pierre
>
>

Hi,
Some Spyder users have reported a critical bug occuring with matplotlib 
0.99's Qt4 backend and PyQt4 v4.6 (e.g. in Ubuntu Karmic).
Here is the traceback after calling 'plot([])', closing figure and 
calling again 'plot([])' (e.g. in an IPython session with options 
--pylab and --q4thread):
Traceback (most recent call last):
 File "/home/rick/Temp/untitled0.py", line 9, in <module>
 show()
 File "/usr/lib/pymodules/python2.6/matplotlib/backends/backend_qt4.py",
line 63, in show
 manager.window.show()
RuntimeError: underlying C/C++ object has been deleted
I found out that the 'destroyed()' signal (connected in class FigureManagerQT) is never emitted when figure is closed.
As a consequence, SIP is not very happy when trying to draw a deleted object...
I made the following changes to make it work:
# New class to clarify code in FigureManagerQT
class FigureWindow(QtGui.QMainWindow):
 def __init__(self, num, canvas, close_callback):
 super(FigureWindow, self).__init__()
 self.close_callback = close_callback
 self.setAttribute(QtCore.Qt.WA_DeleteOnClose)
 self.setWindowTitle("Figure %d" % num)
 image = os.path.join(matplotlib.rcParams['datapath'],
 'images', 'matplotlib.png')
 self.setWindowIcon(QtGui.QIcon(image))
 self._destroying = False
 self.setCentralWidget(canvas)
 if matplotlib.is_interactive():
 self.show()
 
 def closeEvent(self, event):
 super(FigureWindow, self).closeEvent(event)
 self.close_callback()
class FigureManagerQT( FigureManagerBase ):
 """
 Public attributes
 canvas : The FigureCanvas instance
 num : The Figure number
 toolbar : The qt.QToolBar
 window : The qt.QMainWindow
 """
 def __init__( self, canvas, num ):
 if DEBUG: print 'FigureManagerQT.%s' % fn_name()
 FigureManagerBase.__init__( self, canvas, num )
 self.canvas = canvas
 # Give the keyboard focus to the figure instead of the manager
 self.canvas.setFocusPolicy( QtCore.Qt.ClickFocus )
 self.canvas.setFocus()
 self.window = FigureWindow(num, self.canvas, self._widgetclosed)
 self.toolbar = self._get_toolbar(self.canvas, self.window)
 self.window.addToolBar(self.toolbar)
 QtCore.QObject.connect(self.toolbar, QtCore.SIGNAL("message"),
 self.window.statusBar().showMessage)
# [...]
And we may now remove the "QtCore.QObject.disconnect" for the no longer existing signal 'destroyed()' in method 'FigureManagerQT.
destroy'.
HTH
Cheers,
Pierre

It seems that this could be bug in textpath.py that picks up wrong
glyph. Unfortunately, I cannot spend much time on this until the end
of this week.
As a matter of fact, I'm far from an expert on this issue. While I
wrote the textpaht.py, the code is largely based on the code in the
pdf_backend and svg_backend. So, I hope someone who is more
knowledgeable than me step in.
On the other hand, it seems that some glyph-name related bug has
recently fixed in the amsfont. And, this might be related to the
current issue.
http://mirror.math.ku.edu/tex-archive/fonts/amsfonts/doc/README
I'm not sure what version of amsfont you're using but, can you try to
update them to newest 3.0.2 version? And see if that makes any change?
I'll try to look into this later this week.
Regards,
-JJ
On Tue, Nov 3, 2009 at 10:26 PM, tcb <the...@gm...> wrote:
> hi,
>
> i took a quick look at what is going on here- but I have still not quite
> found the problem. From tracing things back into the ft2font code, it seems
> that the wrong glyph index is getting passed in or used somewhere. I put
> this debugging code into ft2font.cpp in "FT2Font::load_glyph"
>
> #define MAX_LEN   1024
>  unsigned char bf[MAX_LEN];
>  FT_Get_Glyph_Name(face, glyph_index, bf, MAX_LEN);
>  std::cout << "FT2Font::load_glyph " << __FILE__ << ":" << __LINE__ << " "
> << glyph_index << " "
>    << num << " "
>    << face->family_name << " "
>    << face->style_name << " "
>    << FT_Get_Postscript_Name(face) << " "
>    << "[ " << bf << " ]"
>    << std::endl;
>
> I modified your example demo_text_path2.py to just load the single symbol
> '\pi' instead '\left[\sum_{n=1}^\infty\frac{-e^{i\pi}}{2^n}\right]' - and
> the output I get is this from the command line:
>
> FT2Font::load_glyph src/ft2font.cpp:1159 25 0 Computer Modern Medium CMMI12
> [ xi ]
>
> so, it seems to pick the correct font but the wrong glyph name (xi instead
> of pi)- I am not sure what the index should be. What gets displayed is the
> '\xi' symbol- you can see from the first output I sent that '\pi' has been
> replaced by '\xi' - the indexes of all the symbols are just offset by one, I
> think.
>
> If the correct glyph index is being passed to ft2font, then it could very
> well be a problem with freetype.
>
> regards
>
>
> On Tue, Nov 3, 2009 at 6:19 PM, tcb <the...@gm...> wrote:
>>
>> Hi,
>>
>> Yes, with the pdfbackend, and using just the plain text code (with
>> usetex=True), the correct output is produced (for Text but not TextPath). I
>> modified your demo_text_path2.py to draw with text, and attached the output.
>>
>> This is the terminal output from running your attached code. I am using
>> the texlive 2009 distribution- which appears to be working fine, I have not
>> noticed any problems at all. What is the difference between the bluesky and
>> amsfonts?
>>
>> texname, type1name, enc, char_id
>> cmex10
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmex10.pfb
>> None CMEX10-34
>> cmsy10
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb
>> None CMSY10-49
>> cmex10
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb
>> None CMEX10-88
>> cmmi12
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi12.pfb
>> None CMMI12-110
>> cmr17
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMR17-61
>> cmr17
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMR17-49
>> cmsy10
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMSY10-0
>> cmmi12
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMMI12-101
>> cmmi12
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMMI12-105
>> cmmi12
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMMI12-25
>> cmr17
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMR17-50
>> cmmi12
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMMI12-110
>> cmex10
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMEX10-35
>> phvr8r
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/urw/helvetic/uhvr8a.pfb
>> /usr/local/texlive/2009/texmf-dist/fonts/enc/dvips/base/8r.enc
>> Nimbus%20Sans%20L%20Regular-2
>>
>> regards,
>>
>>
>> On Tue, Nov 3, 2009 at 2:50 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>>
>>> On Tue, Nov 3, 2009 at 4:23 AM, tcb <the...@gm...> wrote:
>>> > and if I convert the dvi with dvipng, it all seems in order
>>> > (demo_text_path_tex.png). I haven't looked closely into how the
>>> > textpath
>>> > stuff works, but I thought it would read the dvi as a path, and display
>>> > that
>>> > on the screen- if that is correct then I dont know how it ends up
>>> > displaying
>>> > a different symbol from what is in the dvi file.
>>>
>>> Well, dvi files only contains the name of the tex font. What textpath
>>> does is to pick up corresponding type I font and convert them to path
>>> using the freetype library (as far as I know, this is what dvipng and
>>> matplotlib pdf backend does). So, my guess is that, textpath is
>>> somehow picking up wrong fonts, or wrong glyphs.
>>>
>>> The code works fine at least in my mac os X tiger w/ texlive 2008, and
>>> in ubuntu with texlive 2007.
>>> As I don't have any access to mac os X 10.6, it would be hard to track
>>> down what is wrong. Here are a few more test I wish you to run.
>>>
>>> *) Check if pdf backend produces a correct result. Do not use textpath
>>> example, but simply use text command with usetex=True, and see if the
>>> pdf output is okay. FWIW, the textpath code is largely borrowed from
>>> the pdfbackend.
>>>
>>> *) Run the attached code, and post the terminal output. The output is
>>> basically the name of the tex font and the name of the substituted
>>> type1 font, etc. For your reference, here is my output.
>>>
>>> texname, type1name, enc, char_id
>>> cmex10
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmex10.pfb
>>> None CMEX10-34
>>> cmsy10
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmsy10.pfb
>>> None CMSY10-49
>>> cmex10
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmsy10.pfb
>>> None CMEX10-88
>>> cmmi12
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmmi12.pfb
>>> None CMMI12-110
>>> cmr17 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMR17-61
>>> cmr17 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMR17-49
>>> cmsy10
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMSY10-0
>>> cmmi12
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMMI12-101
>>> cmmi12
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMMI12-105
>>> cmmi12
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMMI12-25
>>> cmr17 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMR17-50
>>> cmmi12
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMMI12-110
>>> cmex10
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMEX10-35
>>> pncr8r
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/urw/ncntrsbk/uncr8a.pfb
>>> /usr/local/texlive/2008/texmf-dist/fonts/enc/dvips/base/8r.enc
>>> Century%20Schoolbook%20L%20Roman-232
>>>
>>> Regards,
>>>
>>> -JJ
>>
>
>

Eric Firing wrote:
> jas...@cr... wrote:
>> How hard would it be to extend the quiver command to support curved 
>> arrows? For example, the U and V arrays, instead of giving just the 
>> vector, could for each vector give a list of x coordinates and a list 
>> of y coordinates for each segment of a vector. Additionally, C could 
>> give either a color for the curved vector, or a list of colors for 
>> each segment of the vector.
>
> Very hard. I would recommend starting from scratch with a new class. 
> I think that very little of the present Quiver code would be usable.
Okay. Thanks for the estimate.
Jason