[matplotlib-devel] Enhancement to matplotlib's PyQt4 backend
Hi all,
I would like to contribute to matplotlib with this enhancement for the
PyQt4 backend: the idea is to add a toolbar button to configure figure
options (axes, curves, ...).
It's based on a tiny module called formlayout to generate PyQt4 form
dialog automatically.
Some screenshots:
http://code.google.com/p/formlayout/
So, if you're interested (all the following is GPL2):
*matplotlib patch*
In FigureManagerQT.__init__, added:
self.canvas.axes = self.canvas.figure.add_subplot(111)
In NavigationToolbar2QT._init_toolbar, added:
a = self.addAction(self._icon("customize.png"), 'Customize',
self.edit_parameters)
a.setToolTip('Edit curves line and axes parameters')
Added the following method in NavigationToolbar2QT:
def edit_parameters(self):
from figureoptions import figure_edit
figure_edit(self.canvas, self)
*additionnal modules and data*
formlayout.py (http://code.google.com/p/formlayout/)
figureoptions.py (http://code.google.com/p/PyQtShell/)
customize.png (http://code.google.com/p/PyQtShell/)
cheers,
Pierre
--
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Enhancement to matplotlib's PyQt4 backend
2009/4/28 John Hunter :
>
>
> On Tue, Apr 28, 2009 at 8:18 AM, Pierre Raybaut
> wrote:
>>
>> Hi all,
>>
>> I would like to contribute to matplotlib with this enhancement for the
>> PyQt4 backend: the idea is to add a toolbar button to configure figure
>> options (axes, curves, ...).
>>
>> It's based on a tiny module called formlayout to generate PyQt4 form
>> dialog automatically.
>>
>> Some screenshots:
>> http://code.google.com/p/formlayout/
>>
>> So, if you're interested (all the following is GPL2):
>>
>> *matplotlib patch*
>>
>> In FigureManagerQT.__init__, added:
>> self.canvas.axes = self.canvas.figure.add_subplot(111)
>>
>> In NavigationToolbar2QT._init_toolbar, added:
>> a = self.addAction(self._icon("customize.png"), 'Customize',
>> self.edit_parameters)
>> a.setToolTip('Edit curves line and axes parameters')
>>
>> Added the following method in NavigationToolbar2QT:
>> def edit_parameters(self):
>> from figureoptions import figure_edit
>> figure_edit(self.canvas, self)
>>
>> *additionnal modules and data*
>>
>> formlayout.py (http://code.google.com/p/formlayout/)
>> figureoptions.py (http://code.google.com/p/PyQtShell/)
>> customize.png (http://code.google.com/p/PyQtShell/)
>
> Hi Pierre -- this looks very nice (the last link is broken though , I get a
> 404 error). We would be happy to include this in matplotlib or as a
Here is the last link:
http://code.google.com/p/pyqtshell/
> toolkit. To contribute it to to mpl, the license needs to be matplotlib
> compatible
> (http://matplotlib.sourceforge.net/devel/coding_guide.html#licenses) but we
> have more licensing flexibility in a toolkit, though we prefer to keep
> everything BSD compatible where possible. And of course you would need to
> agree to maintain it :-) but I think many users would appreciate a GUI plot
> configuration dialog.
I was not aware of this license restriction in matplotlib... I fully
understand the motivation, of course, but still: I wrote all this on
my free time which means no PyQt4 commercial license, so it can't be
anything but GPL. Sorry...
Pierre
>
> JDH
>
--
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Enhancement to matplotlib's PyQt4 backend
2009/4/28 Dave Peterson :
> Darren Dale wrote:
>
> On Tue, Apr 28, 2009 at 12:19 PM, Pierre Raybaut
> wrote:
>>
>> 2009/4/28 John Hunter :
>> >
>> >
>> > On Tue, Apr 28, 2009 at 8:18 AM, Pierre Raybaut
>> > wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I would like to contribute to matplotlib with this enhancement for the
>> >> PyQt4 backend: the idea is to add a toolbar button to configure figure
>> >> options (axes, curves, ...).
>> >>
>> >> It's based on a tiny module called formlayout to generate PyQt4 form
>> >> dialog automatically.
>> >>
>> >> Some screenshots:
>> >> http://code.google.com/p/formlayout/
>> >>
>> >> So, if you're interested (all the following is GPL2):
>> >>
>> >> *matplotlib patch*
>> >>
>> >> In FigureManagerQT.__init__, added:
>> >> self.canvas.axes = self.canvas.figure.add_subplot(111)
>> >>
>> >> In NavigationToolbar2QT._init_toolbar, added:
>> >> a = self.addAction(self._icon("customize.png"), 'Customize',
>> >> self.edit_parameters)
>> >> a.setToolTip('Edit curves line and axes parameters')
>> >>
>> >> Added the following method in NavigationToolbar2QT:
>> >> def edit_parameters(self):
>> >> from figureoptions import figure_edit
>> >> figure_edit(self.canvas, self)
>> >>
>> >> *additionnal modules and data*
>> >>
>> >> formlayout.py (http://code.google.com/p/formlayout/)
>> >> figureoptions.py (http://code.google.com/p/PyQtShell/)
>> >> customize.png (http://code.google.com/p/PyQtShell/)
>> >
>> > Hi Pierre -- this looks very nice (the last link is broken though , I
>> > get a
>> > 404 error). We would be happy to include this in matplotlib or as a
>>
>> Here is the last link:
>> http://code.google.com/p/pyqtshell/
>>
>> > toolkit. To contribute it to to mpl, the license needs to be
>> > matplotlib
>> > compatible
>> > (http://matplotlib.sourceforge.net/devel/coding_guide.html#licenses) but
>> > we
>> > have more licensing flexibility in a toolkit, though we prefer to keep
>> > everything BSD compatible where possible. And of course you would need
>> > to
>> > agree to maintain it :-) but I think many users would appreciate a GUI
>> > plot
>> > configuration dialog.
>>
>> I was not aware of this license restriction in matplotlib... I fully
>> understand the motivation, of course, but still: I wrote all this on
>> my free time which means no PyQt4 commercial license, so it can't be
>> anything but GPL. Sorry...
>
> I think you have overlooked a subtlety of PyQt4's license. The author of
> PyQt4 wrote on the enthought-dev mailing list:
>
> "PyQt is GPL but has exceptions that allow it to be used with BSD code -
> hence it's Ok for TraitsBackendQt to be BSD.
>
> However, the exception imposes additional conditions which, to all intents
> and purposes, infects the code with the GPL. To be fair to people that
> should be made clear in any text.
>
> It's still a good idea for TraitsBackendQt to use a BSD license because it
> allows commercial (ie. non-GPL) users to use it without problems."
>
> Darren
>
> I think it might be worth contacting the PyQt folks (Phil Thompson) about
> this. I think there might be some differences here because Phil was the
> author of TraitsBackendQt and thus his efforts didn't quite fall under the
> "develop under a free license, your results needs to be GPL" clause Qt/PyQt
> have in their licensing.
>
> -- Dave
>
>
Hi all,
Dave, you are absolutely right.
Last week-end, I found myself surfing on PyQt's website and I told to
myself: what about re-reading the license? (always a pleasure) And
surprisingly, I found out that anyone using the GPL version of PyQt
can release source code under a very permissive license (like MIT or
BSD) thanks to the PyQt-GPL Exception, as long as PyQt itself is not
part of the distributed package (otherwise the whole package has to be
licensed under GPL) - and with other little restrictions. It was a
surprise because I've read here and there a lot of things on PyQt
license and the general idea was "if you write PyQt code without the
commercial license, your code *must* be licensed under GPL" - I can
tell now that it's not true (to be absolutely certain about it, I even
asked to P
Re: [matplotlib-devel] Enhancement to matplotlib's PyQt4 backend
Gökhan SEVER a écrit : > Hi, > > formlayout will definitely a very nice addition to matplotlib Qt4 > backended plotting windows. It reminds me Traits UI's > configure.traits() method. > > PyQt4 programming is still a mystery to me, and have chosen to learn > Traits instead. > > I am also curious to know what happened to pydee - IPython integration > plans? I changed its priority but the IPython integration in pydee is still planned for this summer. To be honest, I didn't have the time to work on this for a long time now (actually since the IPython PyQt4 frontend demo I've coded in April). In the meantime, I concentrated on cleaning the code, fixing a lot of bugs, improving performances (Workspace mainly) and adding new features: console in a separate process (the "external console": running scripts, debugging, interacting, opening a Python interpreter... with code-completion, calltips, ...), files/directories explorer, class browser, fast code analysis (pyflakes), find in files (next release)... > > I should also mention, I have started a weekly Python meeting in our > department. I highly recommended to Windows users to start with > Python(X,Y). Of course, I agree that is certainly the best thing to do ;-) Pierre > I will see the results next week :) > > Gökhan > > Hi all, > > Dave, you are absolutely right. > > Last week-end, I found myself surfing on PyQt's website and I told to > myself: what about re-reading the license? (always a pleasure) And > surprisingly, I found out that anyone using the GPL version of PyQt > can release source code under a very permissive license (like MIT or > BSD) thanks to the PyQt-GPL Exception, as long as PyQt itself is not > part of the distributed package (otherwise the whole package has to be > licensed under GPL) - and with other little restrictions. It was a > surprise because I've read here and there a lot of things on PyQt > license and the general idea was "if you write PyQt code without the > commercial license, your code *must* be licensed under GPL" - I can > tell now that it's not true (to be absolutely certain about it, I even > asked to Phil Thompson to confirm this, and he did). > > So, I switched all the code I was referring to in my original e-mail > to MIT license. > I guess now it could be integrated to matplotlib Qt4 backend? > > formlayout (generate option dialogs): > http://code.google.com/p/formlayout/ > > pydee (IDE which integrates matplotlib and the option dialog): > http://code.google.com/p/pydee/ > Meanwhile, thanks to the brand new Google-code Mercurial support, you > may browse the source code if you like: > > http://code.google.com/p/pydee/source/browse/pydeelib/widgets/figureoptions.py > > Cheers, > Pierre > -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Qt4 backend: critical bug with PyQt4 v4.6+
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
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
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Qt4 backend: critical bug with PyQt4 v4.6+
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
>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
>
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Qt4 backend: critical bug with PyQt4 v4.6+
>
> On Wed, Nov 4, 2009 at 5:29 PM, Pierre Raybaut wrote:
>
>> > 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.
>>
>
> I am pretty sure this is not caused by matplotlib, but rather a
> regression in PyQt4 that will be fixed in the next release. There is a
> post on the PyQt mailing list titled "Regressions on destruction of
> objects?" and a note in the development snapshots changelog. If I try
> your example with PyQt4-4.5.4, it works fine, but it crashes with
> 4.6.1. I will revisit the issue once PyQt4-4.7 is released.
>
> Darren
>
I completely agree -- in the meantime I checked that despite the
QMainWindow instance has been destroyed, the 'destroyed()' signal is not
emitted, so the problem is definitely coming from PyQt4, not matplotlib.
However, to help unfortunate users of PyQt4 v4.6 and v4.6.1, I've added
the following workaround in Spyder (Spyder is monkey patching matplotlib
anyway, to integrate mpl dockable figures in Spyder's GUI) -- other
users may be interested to patch their matplotlib installation
(matplotlib/backends/backend_qt4.py):
# Add this before "FigureManagerQT" class
class FigureWindow(QMainWindow):
def __init__(self):
super(FigureWindow, self).__init__()
def closeEvent(self, event):
super(FigureWindow, self).closeEvent(event)
if PYQT_VERSION_STR.startswith('4.6'):
self.emit(SIGNAL('destroyed()'))
# Replace "QtGui.QMainWindow" by "FigureWindow" in "FigureManagerQT"'s
constructor
I hope this will be fixed in v4.6.2.
Cheers,
Pierre
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Qt4 backend: critical bug with PyQt4 v4.6+
2009/12/31 Fernando Perez : > On Thu, Dec 31, 2009 at 4:54 AM, Darren Dale wrote: >> I have been resistant to committing this patch because (in my opinion) >> mpl should not have to provide workarounds for bugs in package X on OS >> Y, distribution Z. I think this particular issue was fixed when >> PyQt4-4.6.2 was released. But its time to get practical, I suppose. >> The patch looks fine, I just checked it into the trunk. > > Thanks! As the zen goes, practicality beats purity :) I understand > your reluctance though, it's annoying to pepper mpl's code with this > kind of junk. > > Happy New Year! > > f > I completely agree. If developers were all doing their "job" in time, this should not be necessary and Darren's position would be perfectly right and justified. However, especially on certain open-source libraries, things are not moving as fast as they should. For example, in Spyder I had to re-implement a console-oriented text editor widget with Scintilla-like features because QScintilla's widget had a performance issue with very long lines (which is almost undectectable when using it as a simple text editor but it may slow down display when using it as a console widget). This bug was fixed just a few days after being reported but there has been no release since then (August 2009). So, to make it work, I had to do this big workaround until the next release of QScintilla has spread on every platform (i.e. not until a year I guess). In terms of code refactoring (or purity...), this was not very satisfying but now Spyder works perfectly because I stopped saying "it's not my fault, it's QScintilla's". So even if I agree with Darren on the fact that libraries such as matplotlib should not provide this kind of workaround, I also think that -at some point- one has to get practical indeed! Happy new year guys! Cheers, Pierre -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Numpy-discussion] Announcing toydist, improving distribution and packaging situation
Hi David, Following your announcement for the 'toydist' module, I think that your project is very promising: this is certainly a great idea and it will be very controversial but that's because people expectactions are great on this matter (distutils is so disappointing indeed). Anyway, if I may be useful, I'll gladly contribute to it. In time, I could change the whole Python(x,y) packaging system (which is currently quite ugly... but easy/quick to manage/maintain) to use/promote this new module. Happy New Year! and Long Live Scientific Python! ;-) Cheers, Pierre -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [SPAM] Re: [SciPy-User] [Numpy-discussion] Announcing toydist, improving distribution and packaging situation
2010/1/2 David Cournapeau : > On Fri, Jan 1, 2010 at 10:43 PM, Pierre Raybaut wrote: >> Hi David, >> >> Following your announcement for the 'toydist' module, I think that >> your project is very promising: this is certainly a great idea and it >> will be very controversial but that's because people expectactions are >> great on this matter (distutils is so disappointing indeed). >> >> Anyway, if I may be useful, I'll gladly contribute to it. >> In time, I could change the whole Python(x,y) packaging system (which >> is currently quite ugly... but easy/quick to manage/maintain) to >> use/promote this new module. > > That would be a good way to test toydist on a real, complex package. I > am not familiar at all with python(x,y) internals. Do you have some > explanation I could look at somewhere ? Honestly, let's assume that there is currently no packaging system... it would not be very far from the truth. I did it when I was young and naive regarding Python. Actually I almost did it without having writing any code in Python (approx. two months after earing about the Python language for the first time) : it's an ugly collection of AutoIt, NSIS and PHP scripts -- most of the tasks are automated like updating the generated website pages and so on. So I'm not proud at all, but it was easy and very quick to do as it is, and it's still quite easy to maintain. But, it's not satisfying in terms of code "purity" -- I've been wanting to rewrite all this in Python for a year and a half but since the features are there, there is no real motivation to do the work (in other words, Python(x,y) users would not see the difference, at least at the beginning). An other thing: Python(x,y) plugins are not built from source but from existing binaries (it's a pity I know, but it was incredibly faster to do this way). For example, eggs or distutils .exe may be converted in Python(x,y) plugins directly (same internal directory structure). So it may be different from the idea you had in mind (it's not like EPD which is entirely generated from source, AFAIK). > In the meantime, I will try to clean-up the code to have a first > experimental release. > Ok, keep up the good work! Cheers, Pierre -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [SPAM] Re: Enhancement to matplotlib's PyQt4 backend
2010/1/3 Darren Dale : > On Sun, Jan 3, 2010 at 9:11 AM, Pierre Raybaut wrote: >> 2009/12/1 Darren Dale : >>> On Tue, Apr 28, 2009 at 8:18 AM, Pierre Raybaut >>> wrote: >>>> Hi all, >>>> >>>> I would like to contribute to matplotlib with this enhancement for the >>>> PyQt4 backend: the idea is to add a toolbar button to configure figure >>>> options (axes, curves, ...). >>>> >>>> It's based on a tiny module called formlayout to generate PyQt4 form >>>> dialog automatically. >>>> >>>> Some screenshots: >>>> http://code.google.com/p/formlayout/ >>>> >>>> So, if you're interested (all the following is GPL2): >>>> >>>> *matplotlib patch* >>> >>> Would you please submit an actual patch? I don't know exactly where >>> you intend these changes to be placed. >>> >>>> In FigureManagerQT.__init__, added: >>>> self.canvas.axes = self.canvas.figure.add_subplot(111) >>> >>> What is the purpose of this change? What if I didn't want such an axes >>> on my canvas? What if I want to layout my own axes([.2,.2,.75,.75]) or >>> add_subplot(311)? I don't think these changes can be accepted in the >>> current form, they don't appear to integrate well with the standard >>> behavior of the library. >>> >>> Darren >> >> Ok, I admit that it was very difficult to fix this -- it took me a lot >> of seconds without knowing very well matplotlib... ;-) > > [...] > >> Here is a zip file containing all you need (patch for backend_qt4.py, >> two scripts to be copied in backends/, and one .svg image to be copied >> to mpl-data/images/) > > [...] > > Your patch file is backwards, it would revert your changes if applied > to the updated code. Sorry for this... I admit that I did this maybe too quickly. > It doesn't matter, the patch is so small that the > changes can just be cut and pasted. Unfortunately, however, I will not > have time to review your contribution closely enough to consider > committing it for at least two weeks, maybe more (conference and long > hours at work). I'll look into it when I get a chance, if someone else > doesn't beat me to it. > > Darren No problem, this is already part of Spyder's matplotlib patch for six months now, and I'm only using matplotlib through Spyder, so there is absolutely no hurry for me. Since the beginning I was just trying to be useful, to share something. I simply thought that this kind of feature was missing in matplotlib: matplotlib produces good looking figures but -compared to MATLAB- there is a serious lack of interactivity (and performance -- but matplotlib is at worst as slow as MATLAB, so it doesn't matter much). Pierre -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Enhancement to matplotlib's PyQt4 backend
2010/1/3 John Hunter : > On Sun, Jan 3, 2010 at 9:28 AM, Darren Dale wrote: > >> Your patch file is backwards, it would revert your changes if applied >> to the updated code. It doesn't matter, the patch is so small that the >> changes can just be cut and pasted. Unfortunately, however, I will not >> have time to review your contribution closely enough to consider >> committing it for at least two weeks, maybe more (conference and long >> hours at work). I'll look into it when I get a chance, if someone else >> doesn't beat me to it. > > Hey Pierre, Darren, > > I took a stab at this. I put the helper code in a backends.qt4_editor > package, and put the toolbar button right after the configure subplots > button. Thanks for the patch and the license change Pierre, and sorry > it took us so long to incorporate it. Let me know if any of the > reorganizations are a problem for you. > > JDH > That is perfect! Thanks very much John. Pierre -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Enhancement to matplotlib's PyQt4 backend
John, Following to your last commit on "added qt4_editor dialog" (rev 8064), here is a significant (but simple) improvement adding an "Apply" button to the option dialog box (very convenient) -- suggested by Gökhan. (attached diff files should patch formlayout.py and figureoptions.py as in rev. 8064) Thanks, Pierre 2010/1/3 John Hunter : > On Sun, Jan 3, 2010 at 2:41 PM, Gökhan Sever wrote: >> You seemed like forgetting to check-in the qt4_editor_options.svg, because I >> get file not found error: >> >> I[2]: Cannot open file >> '.../matplotlib/lib/matplotlib/mpl-data/images/qt4_editor_options.svg', >> because: No such file or directory > > > Oops, just added. Thanks for the head's up. > > JDH > formlayout.py.diff Description: Binary data figureoptions.py.diff Description: Binary data -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Enhancement to matplotlib's PyQt4 backend
Hi Darren, > -Message d'origine- > De : Darren Dale [mailto:dsdal...@gmail.com] > Envoyé : dimanche 27 février 2011 22:02 > À : Pierre Raybaut > Cc : matplotlib-devel > Objet : Re: [matplotlib-devel] Enhancement to matplotlib's > PyQt4 backend > > On Sun, Feb 27, 2011 at 3:27 PM, Darren Dale > wrote: > > Hi Pierre, > > > > Are you still maintaining the qt4 plot editor dialog? It doesn't > > appear to be working properly: setting the marker and linestyle > > options does not effect the plot (tested on Ubuntu Natty > alpha, with > > the v1.0.x branch on python-2.7 and PyQt4-4.8.3). > > Sorry, I think this was a mistake on my part... > > > I have a really hard > > time following the code. > > ... but I do have a really hard time understanding the code. Well it seems quite self-explanatory to me (especially the 'formlayout' module which is very OO which tends to hide code complexity), hence the lack of comments. But hey, I wrote it so I guess it's easier for me to read it. Anyway, please don't hesitate to ask questions about the part of the code that seems unclear. > > Also, the dialog makes the qt4 backend unusable with > PyQt4's API v2, > > which does not provide a QString object. > > This can be addressed with the following change, which I just > > @@ -56,9 +56,9 @@ from PyQt4.QtGui import (QWidget, > QLineEdit, QComboBox, QLabel > QPixmap, QTabWidget, QApplication, > QStackedWidget, > QDateEdit, QDateTimeEdit, QFont, > QFontComboBox, > QFontDatabase, QGridLayout) -from > PyQt4.QtCore import (Qt, SIGNAL, SLOT, QSize, QString, > +from PyQt4.QtCore import (Qt, SIGNAL, SLOT, QObject, QSize, >pyqtSignature, pyqtProperty) > import datetime > > > class ColorButton(QPushButton): > @@ -102,7 +102,8 @@ def text_to_qcolor(text): > Avoid warning from Qt when an invalid QColor is instantiated > """ > color = QColor() > -if isinstance(text, QString): > +if isinstance(text, QObject): > +# actually a QString, which is not provided by the > new PyQt4 API: > text = str(text) > if not isinstance(text, (unicode, str)): > return color > This seems ok to me. Cheers, Pierre -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Bug when embedding Matplotlib 0.91.2 in PyQt 4.4.2
Hi all, First, I would like to congratulate you for your work on Matplotlib. I am using Matplotlib widgets in all my current projects, embedded in PyQt graphical user interfaces. As you may know, PyQt 4.4.2 has been released a few days ago. And I found out a performance bug when embedding a Matplotlib 0.91.2 canvas in a PyQt 4.4.2 object: the pan/zoom feature is very slow (with PyQt 4.3.3, and the exact same scripts, pan/zoom is real-time). I am posting this in PyQt mailing-list too, but I guess that you could have more ideas on that matter (Matplotlib widgets may not be used very often in PyQt). Thanks for your help! Regards, Pierre Raybaut - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug when embedding Matplotlib 0.91.2 in PyQt 4.4.2
> > Hi Pierre, > > On Friday 30 May 2008 5:21:01 pm Pierre Raybaut wrote: > >> > First, I would like to congratulate you for your work on Matplotlib. I >> > am using Matplotlib widgets in all my current projects, embedded in PyQt >> > graphical user interfaces. >> > >> > As you may know, PyQt 4.4.2 has been released a few days ago. >> > And I found out a performance bug when embedding a Matplotlib 0.91.2 >> > canvas in a PyQt 4.4.2 object: the pan/zoom feature is very slow (with >> > PyQt 4.3.3, and the exact same scripts, pan/zoom is real-time). >> > > Would it be possible to post some benchmarks, something a little more > concrete, like specifically what calls are taking the most time, and how they > compare for the different versions of PyQt? > Yes of course, I will send the requested informations as soon as I can. > >> > I am posting this in PyQt mailing-list too, but I guess that you could >> > have more ideas on that matter (Matplotlib widgets may not be used very >> > often in PyQt). >> > > Please don't do that. Its not fair to the people who volunteer their time on > open source projects to try to draw so many people into the problem before > the problem is understood. Wow... I did not expect this reaction! :) The only reason that I posted on the two mailing-list was to be sure to inform everyone who was potentially interested by the topic. Otherwise, if I was really trying outrageously to draw many people into the problem, I wouldn't have mentioned the post on the other mailing-list, would I? Thanks for the warm welcome though ;) Regards, Pierre Raybaut - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug when embedding Matplotlib 0.91.2 in PyQt 4.4.2
2008/6/3 Darren Dale <[EMAIL PROTECTED]>: > On Sunday 01 June 2008 04:10:45 am Pierre Raybaut wrote: > Sorry, I didn't mean to seem brusque. If there is a problem with > matplotlib's > qt4 support, I would prefer to have a chance to look into it before the > problem is announced to the pyqt community. > No problem, I understand your concern and completely agree: I'll be more cautious in the future. > > I tried putting some print statements in backend_qt4agg to see how long it > was > taking to draw the canvas: > >def draw( self ): >""" >Draw the figure when xwindows is ready for the update >""" > >if DEBUG: print "FigureCanvasQtAgg.draw", self >self.replot = True >d0 = time.time() >FigureCanvasAgg.draw(self) >d = time.time() >print d-d0, 'agg:draw' >d0=d >self.update() >print time.time()-d0, 'qt4:update' > > FigureCanvasAgg.draw(self) takes about .02 seconds, and self.update() takes > less than .0004 seconds. FigureCanvasAgg.draw is independent of qt/pyqt, so > it look like panning/zooming is limited only by how fast matplotlib/agg can > draw the canvas on my machine, which has qt-4.4.0 and PyQt4-4.4.2. > On my computer, FigureCanvasAgg.draw(self) takes 16 ms (basically the same duration as yours), and self.update() takes 0 second, for both PyQt 4.3.3 and 4.4.2 - and there is still clearly a display performance issue with release 4.4.2 (apparently, the draw and update features take the same time, but on screen, panning/zooming refresh rate is clearly lower than with PyQt 4.3.3). So it seems that it is not a good way to measure the display performance, and honestly I don't know maplotlib enough to see how to do the right benchmark. Pierre - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Bug in Qt4 backend (navigation toolbar destroy method)
Hi all, I'm posting to report the following bug in 'backend_qt4.py', class 'NavigationToolbar2QT' l. 309 : When using Qt4 as default backend, if you type 'plot(x,y)' and then 'close()', you'll obtain an attribute error because 'NavigationToolbar2QT' has no 'toolitem' attribute (see line 310). I think that 'toolitem' was used in the previous Qt4 backend implementation. To make things work, I simply removed this 'destroy' method which is probably deprecated. Regards, Pierre Raybaut - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Bugs in Qt4 backend with the latest PyQt release
Hi all, I'm posting to report two bugs in 'backend_qt4.py' with the latest PyQt release: (see eventually the attached test script) (1) in class 'NavigationToolbar2QT' l. 285-300 : I had to replace '.svg' by '.png' for all the icons to be displayed correctly on the navigation toolbar (only one was already loaded in the right file format). (2) I still experience slow performance of pan/zoom feature with the latest PyQt release (the last release for which I had no problem is the 4.3.3 release). You'll find attached a simple test script: with PyQt 4.3.3 pan/zoom is real-time, and with PyQt 4.4.3 it's really slower (in fact, zooming and panning are happening at the right speed but after a short delay from the mouse click) Regards, Pierre Raybaut #!/usr/bin/env python import sys, os from PyQt4 import QtGui, QtCore from numpy import arange, sin, pi from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as FigureCanvas from matplotlib.figure import Figure from matplotlib.backends.backend_qt4 import NavigationToolbar2QT from matplotlib.backend_bases import NavigationToolbar2 class MplCanvas(FigureCanvas): def __init__(self, parent=None, width=5, height=4, dpi=100): fig = Figure(figsize=(width, height), dpi=dpi) self.axes = fig.add_subplot(111) self.axes.hold(False) self.compute_initial_figure() FigureCanvas.__init__(self, fig) self.setParent(parent) FigureCanvas.setSizePolicy(self,QtGui.QSizePolicy.Expanding,QtGui.QSizePolicy.Expanding) FigureCanvas.updateGeometry(self) def compute_initial_figure(self): t = arange(0.0, 3.0, 0.01) self.axes.plot(t, sin(2*pi*t)) class Toolbar(NavigationToolbar2QT) : def __init__(self , parent , canvas, coordinates=True) : self.canvas = canvas self.coordinates = coordinates QtGui.QWidget.__init__( self, parent ) NavigationToolbar2.__init__( self, canvas ) NavigationToolbar2.pan(self) class ApplicationWindow(QtGui.QMainWindow): def __init__(self): QtGui.QMainWindow.__init__(self) self.setAttribute(QtCore.Qt.WA_DeleteOnClose) self.main_widget = QtGui.QWidget(self) l = QtGui.QVBoxLayout(self.main_widget) sc = MplCanvas(self.main_widget, width=5, height=4, dpi=100) l.addWidget(sc) l.addWidget(Toolbar(sc , sc)) self.main_widget.setFocus() self.setCentralWidget(self.main_widget) qApp = QtGui.QApplication(sys.argv) aw = ApplicationWindow() aw.show() sys.exit(qApp.exec_())- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bugs in Qt4 backend with the latest PyQt release
Hi Darren, 2008/8/18 Darren Dale <[EMAIL PROTECTED]>: >> (1) in class 'NavigationToolbar2QT' l. 285-300 : I had to replace '.svg' >> by '.png' for all the icons to be displayed correctly on the navigation >> toolbar (only one was already loaded in the right file format). > > Could this be a problem with your installation of Qt4? I have been using the I really don't know, I'll have to check this. I really thought it was a bug because the icons aren't all in the same format as if they were partially replaced from svg to png for example, so I didn't think it could come from my installation. But I'll check my installation. > svg icons for a while now, without any issues. In what way are they displayed > incorrectly? They are not displayed at all. > Did you compile qt4 without svg support? I use the official PyQt binaries, so yes, I guess. > >> (2) I still experience slow performance of pan/zoom feature with the >> latest PyQt release (the last release for which I had no problem is the >> 4.3.3 release). You'll find attached a simple test script: with PyQt >> 4.3.3 pan/zoom is real-time, and with PyQt 4.4.3 it's really slower (in >> fact, zooming and panning are happening at the right speed but after a >> short delay from the mouse click) > > I think I need a more quantitative test script that proves this is an issue > with mpl before I can be of help. On my machine, panning and zooming is just > as fast with your test script as it is with a simple test plot in pylab using > either the qt4agg or gtkagg backends. I have qt-4.4.1 and PyQt4-4.4.2 > installed. Is there anyway you can profile the poor performance you are > seeing? Is your machine under Windows? If you need something to prove that this has nothing to do with my machine or my software, I can tell you that there is exactly the same bug on a virtual machine, after a clean Windows XP install, and using only the official Python MSI installer and the official PyQt installer (and the latest matplotlib release of course). I also saw the same bug on three other machines, but the real proof is the VM. So I will take a look again at the 'backend_qt4.py' source code to see if there is a way to profile this poor performance. Thanks Pierre > > Darren > > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bugs in Qt4 backend with the latest PyQt release
Darren Dale a écrit : >> If you need something to prove that this has nothing to do with my >> machine or my software, I can tell you that there is exactly the same >> bug on a virtual machine, after a clean Windows XP install, and using >> only the official Python MSI installer and the official PyQt installer >> (and the latest matplotlib release of course). I also saw the same bug >> on three other machines, but the real proof is the VM. >> > > I'm not familiar with virtual machines, so I guess I dont understand what > that > proves. I'm looking for something that indicates this is an issue with > matplotlib and not Qt. You found a problem once you upgraded from 4.3.3, but > I have not seen a similar problem. I'll try running your test script on a > I've just received another proof (I know that it does not solve the problem, but I'm feeling less lonely!): a canadian Python/Qt user experienced exactly the same bug (and he did the test on three different machines, two with XP and one with Vista). > windows machine tonight, but in the meantime, perhaps you could try to > determine if there is a step in backend_qt4agg.FigureCanvasQTAgg.paintEvent > (or somewhere else) that is the source of the bottleneck. > What do you mean exactly? Pierre - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bugs in Qt4 backend with the latest PyQt release
Hi Darren, 2008/8/18 Darren Dale <[EMAIL PROTECTED]>: > Nevermind. It turns out its not exactly poor performance, but for some reason > the gui events were not getting processed as frequently on windows. Maybe Qt > changed something in an attempt to optimize performance. > > I applied a patch in svn 6043, but its a really simple fix. At the end of > backend_qt4agg.FigureCanvasQTAgg.draw, after self.update(), add this line: > >QtGui.qApp.processEvents() > > It seemed to improve things on my windows laptop, but let me know if it fixes > the problem for you. Good work Darren, thanks, it works perfectly! That is great news because I found (and reported) this bug three months ago, so I was beginning to worry about the future of Qt4 backend. Now I can consider updating PyQt in Python(x,y). > I forgot to mention, the svg icons display fine for me with windows xp, > matplotlib-0.98. Forget about it, I've just found out that this is related to one of my own-made packages. Thanks Pierre - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] re lease schedule for next version
Le 25/02/2012 22:59, John Hunter a écrit :
On Sat, Feb 25, 2012 at 1:54 PM, Benjamin Root wrote:
>
>> > I would be interested in accelerating the schedule. Since this is a
>> > bug-fix release and not a major release, we can presume the tree is
>> > pretty stable. How about we aim for an release candidate rc1 the
>> > week after next? Are there any issues or pull requests that should
>> > hold the release? If so, let's tag them with release-critical.
>> >
>> > After we get the bugfix out I'd like to gear up for a major python3
>> > release.
>> >
>> >
>> > The QT4 event handling bugs needs a qt expert on them. I tried looking
>> > into them and there is no obvious reason to me why they aren't working.
>>
>> Are you referring to 771, 707, and 525? 771 would appear to be the
>> most urgent.
>
>
> 711 and 707. Didn't even notice 525, but it is probably related to
> 707. If true, then 707 and 525 are likely focus issues (maybe
> window-manager dependent?). 711 definitely seem to be release blocking.
>
>
Hi Pierre, we are still having trouble with the close event in mpl figure
windows not being emitted. I see you posted on this subject in 2009 and
did some monkey patching to work around the problem for spyder
http://old.nabble.com/Qt4-backend%3A-critical-bug-with-PyQt4-v4.6%2B-td26205716.html
This was a while ago so I don't know if your suggestions are still
appropriate for recent pyqt and mpl. Would you have a minute to take a
look at this mpl issue
https://github.com/matplotlib/matplotlib/issues/711
and advise us on a fix?
Thanks,
JDH
Hi John,
Replacing this (backend_qt4.py, class "FigureCanvasQT", line 141):
QtCore.QObject.connect(self, QtCore.SIGNAL('destroyed()'),
self.close_event)
by this:
QtCore.QObject.connect(self, QtCore.SIGNAL('destroyed()'),
lambda: self.close_event())
will solve this issue.
The reason is that PyQt fails (silently) to call a method of this object
just before detroying it. Using a lambda function will work, exactly the
same as using a function (which is not bound to the object to be destroyed).
Side note: I'm not sure that it's the intended behavior for PyQt...
HTH,
Pierre
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] re lease schedule for next version
I found out that a similar issue was reported for Spyder the same day
as this one...
So I just posted something about this bug on PyQt mailing list:
http://www.riverbankcomputing.com/pipermail/pyqt/2012-February/031166.html
-Pierre
Le 26 février 2012 12:23, Pierre Raybaut a écrit :
> Le 25/02/2012 22:59, John Hunter a écrit :
>
>
>
> On Sat, Feb 25, 2012 at 1:54 PM, Benjamin Root wrote:
>>>
>>>
>>> > I would be interested in accelerating the schedule. Since this is
>>> > a
>>> > bug-fix release and not a major release, we can presume the tree is
>>> > pretty stable. How about we aim for an release candidate rc1 the
>>> > week after next? Are there any issues or pull requests that should
>>> > hold the release? If so, let's tag them with release-critical.
>>> >
>>> > After we get the bugfix out I'd like to gear up for a major python3
>>> > release.
>>> >
>>> >
>>> > The QT4 event handling bugs needs a qt expert on them. I tried looking
>>> > into them and there is no obvious reason to me why they aren't working.
>>>
>>> Are you referring to 771, 707, and 525? 771 would appear to be the
>>> most urgent.
>>
>>
>> 711 and 707. Didn't even notice 525, but it is probably related to 707.
>> If true, then 707 and 525 are likely focus issues (maybe window-manager
>> dependent?). 711 definitely seem to be release blocking.
>>
>
>
> Hi Pierre, we are still having trouble with the close event in mpl figure
> windows not being emitted. I see you posted on this subject in 2009 and did
> some monkey patching to work around the problem for spyder
>
> http://old.nabble.com/Qt4-backend%3A-critical-bug-with-PyQt4-v4.6%2B-td26205716.html
>
> This was a while ago so I don't know if your suggestions are still
> appropriate for recent pyqt and mpl. Would you have a minute to take a look
> at this mpl issue
>
> https://github.com/matplotlib/matplotlib/issues/711
>
> and advise us on a fix?
>
> Thanks,
> JDH
>
>
>
>
> Hi John,
>
> Replacing this (backend_qt4.py, class "FigureCanvasQT", line 141):
> QtCore.QObject.connect(self, QtCore.SIGNAL('destroyed()'),
> self.close_event)
> by this:
> QtCore.QObject.connect(self, QtCore.SIGNAL('destroyed()'),
> lambda: self.close_event())
> will solve this issue.
>
> The reason is that PyQt fails (silently) to call a method of this object
> just before detroying it. Using a lambda function will work, exactly the
> same as using a function (which is not bound to the object to be destroyed).
>
> Side note: I'm not sure that it's the intended behavior for PyQt...
>
> HTH,
> Pierre
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Upstream Matplotlib Qt Designer Plugin
Hi all, Is anyone interested in including the Matplotlib QtDesigner plugin which I wrote for Python(x,y)? The code is quite simple and hasn't evolved for a while now (3 years) but apparently it is still appreciated by users even outside Python(x,y). Here are the two files which are necessary to make this plugin work: http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/matplotlibwidget.py http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/PyQt4/plugins/designer/python/matplotlibplugin.py The directory struture also has its importance: http://code.google.com/p/pythonxy/source/browse/#hg%2Fsrc%2Fpython%2Fmatplotlib%2FQtDesigner_Plugins Cheers, Pierre -- Message transféré -- De : todd rme Date : 11 mars 2012 12:14 Objet : [python(x,y)] Upstream Matplotlib Qt Designer Plugin À : "python(x,y)" I notice that python(x,y) has a matplotlib plugin for Qt Designer. I think this would be very helpful for general users of matplotlib outside of python(x,y). Is there any possibility of submitting this plugin upstream for inclusion with the official matplotlib release? That way people who aren't using python(x,y) (for instance Linux users who are using their official distribution python packages) could benefit from the plugin as well. Thank you very much. -Todd -- You received this message because you are subscribed to the Google Groups "python(x,y)" group. To post to this group, send email to pytho...@googlegroups.com. To unsubscribe from this group, send email to pythonxy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pythonxy?hl=en. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
