As of 1.1.0, FigureCanvasQTAgg.draw() now no longer calls
FigureCanvasAgg.draw(), and as a result I am getting problems with code that
used to update positions/size of legend and labels during on_draw.
1. Is there a new way to get the canvas to draw? or is this a bug?
2. I cannot see any reference to PyQt4v2 in the code, and any attempt to set
the rcParam to use it results in a param validation error, is this a mistake
in the web page or omission in the code?
I think that might have been a little unclear. You should only need to select ‘PyQt4’ or ‘PySide’. If PyQt4 is selected, then (I think) the v2 is automatically tested for internally.
Ben Root
···
On Tue, Oct 18, 2011 at 11:19 AM, RuiDC <ruidc@…9…> wrote:
As of 1.1.0, FigureCanvasQTAgg.draw() now no longer calls
FigureCanvasAgg.draw(), and as a result I am getting problems with code that
used to update positions/size of legend and labels during on_draw.
1. Is there a new way to get the canvas to draw? or is this a bug?
The problem is that all drawing is now deferred until a paintEvent occurs. draw() is using the update() method to queue the request for a paintEvent, where all actual drawing is done, consistent with what I understand to be the recommended mode of operation for QT, but maybe not with the way mpl operates; it has the effect of making draw() work like draw_idle().
It looks like what I should do is move the call to FigureCanvasAgg.draw back into the FigureCanvasQTAgg.draw method. I'll give it a try.
2. I cannot see any reference to PyQt4v2 in the code, and any attempt to set
the rcParam to use it results in a param validation error, is this a mistake
in the web page or omission in the code?
As of 1.1.0, FigureCanvasQTAgg.draw() now no longer calls
FigureCanvasAgg.draw(), and as a result I am getting problems with code that
used to update positions/size of legend and labels during on_draw.
1. Is there a new way to get the canvas to draw? or is this a bug?
I would say it is a bug that has been lurking undetected for 9 months.
2. I cannot see any reference to PyQt4v2 in the code, and any attempt to set
the rcParam to use it results in a param validation error, is this a mistake
in the web page or omission in the code?
I think that might have been a little unclear. You should only need to
select ‘PyQt4’ or ‘PySide’. If PyQt4 is selected, then (I think) the v2 is
automatically tested for internally.
hmm, please explain where you think it is used internally, as the code seem to expect that this param can be set when there is no env variable ‘QT_API’ set, in backends\qt4_compat.py:
# Available APIs.
QT_API_PYQT = 'PyQt4' # API is not set here; Python 2.x default is V 1
QT_API_PYQTv2 = 'PyQt4v2' # forced to Version 2 API
QT_API_PYSIDE = 'PySide' # only supports Version 2 API
ETS = dict(pyqt=QT_API_PYQTv2, pyside=QT_API_PYSIDE)
# If the ETS QT_API environment variable is set, use it. Note that
# ETS requires the version 2 of PyQt4, which is not the platform
# default for Python 2.x.
QT_API_ENV = os.environ.get('QT_API')
if QT_API_ENV is not None:
try:
QT_API = ETS[QT_API_ENV]
except KeyError:
raise RuntimeError(
'Unrecognized environment variable %r, valid values are: %r or %r' %
(QT_API_ENV, 'pyqt', 'pyside'))
else:
# No ETS environment, so use rcParams.
QT_API = rcParams['backend.qt4']
but trying to set it, via code or matplotlibrc results in:
Great, thanks for confirming and fixing!
Whilst waiting for this to make it into a release, I’ve hacked this to achieve the same effect (so I don’t have to patch + distribute the mpl code):
Benjamin Root-2 wrote:
I think that might have been a little unclear. You should only need
to select 'PyQt4' or 'PySide'. If PyQt4 is selected, then (I think)
the v2 is automatically tested for internally.
hmm, please explain where you think it is used internally, as the code
seem to expect that this param can be set when there is no env variable
'QT_API' set, in backends\qt4_compat.py:
After quite a bit of thrashing around, we settled on the present system. The rcParam deliberately does *not* set the API version if PyQt4 is used. Whatever your Qt4 comes up with when the backend is imported is what is used. That way there is no conflict with applications that import pyqt4, and perhaps set the API, before importing mpl. If you want to use the v2 api, you can import pyqt4 and set the API yourself before importing mpl. Or, if you want the API to be forced to v2 by mpl when the backend is imported, you can do what ETS does, which is to set the QT_API environment variable to "pyqt".
This moderately ugly mess was necessitated by the need to be compatible with ipython, ETS, and existing user code, while dealing with two versions of pyqt4 and one of pyside, and with different default versions of pyqt4 for python 2 and python 3 (which we will be supporting in the not-too-distant future, I believe.)
Eric
···
On 10/18/2011 09:44 PM, RuiDC wrote:
# Available APIs.
QT_API_PYQT = 'PyQt4' # API is not set here; Python 2.x default is V 1
QT_API_PYQTv2 = 'PyQt4v2' # forced to Version 2 API
QT_API_PYSIDE = 'PySide' # only supports Version 2 API
# If the ETS QT_API environment variable is set, use it. Note that
# ETS requires the version 2 of PyQt4, which is not the platform
# default for Python 2.x.
QT_API_ENV = os.environ.get('QT_API')
if QT_API_ENV is not None:
try:
QT_API = ETS[QT_API_ENV]
except KeyError:
raise RuntimeError(
'Unrecognized environment variable %r, valid values are: %r or %r' %
(QT_API_ENV, 'pyqt', 'pyside'))
else:
# No ETS environment, so use rcParams.
QT_API = rcParams['backend.qt4']
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct