QT draw issue in 1.1.0 and PyQt4v2 missing?

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 "what's new in 1.1.0" page,
http://matplotlib.sourceforge.net/users/whats_new.html refers to:
"An rcParam entry, “backend.qt4”, has been added to allow users to select
PyQt4, PyQt4v2, or PySide."

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?

Thanks in advance
RuiDC

···


View this message in context: http://old.nabble.com/QT-draw-issue-in-1.1.0-and-PyQt4v2-missing--tp32676093p32676093.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

RuiDC,

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:

The “what’s new in 1.1.0” page,

http://matplotlib.sourceforge.net/users/whats_new.html refers to:

"An rcParam entry, “backend.qt4”, has been added to allow users to select

PyQt4, PyQt4v2, or PySide."

  1. 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?

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.

Eric

···

On 10/18/2011 06:19 AM, RuiDC wrote:

The "what's new in 1.1.0" page,
http://matplotlib.sourceforge.net/users/whats_new.html refers to:
"An rcParam entry, “backend.qt4”, has been added to allow users to select
PyQt4, PyQt4v2, or PySide."

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?

Thanks in advance
RuiDC

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.

https://github.com/matplotlib/matplotlib/pull/539

I think this pull request fixes it.

Eric

···

On 10/18/2011 06:19 AM, RuiDC wrote:

The "what's new in 1.1.0" page,
http://matplotlib.sourceforge.net/users/whats_new.html refers to:
"An rcParam entry, “backend.qt4”, has been added to allow users to select
PyQt4, PyQt4v2, or PySide."

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?

Thanks in advance
RuiDC

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:


# 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:

Unrecognized backend.qt4 string “PyQt4v2”: valid strings are [‘PySide’, ‘PyQt4’]
“%s”\n\t%s’ % (val, cnt, line, fname, msg))

···

View this message in context: Re: QT draw issue in 1.1.0 and PyQt4v2 missing?

Sent from the matplotlib - users mailing list archive at Nabble.com.

efiring wrote:

https://github.com/matplotlib/matplotlib/pull/539
I think this pull request fixes it.
Eric

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):

        def do_draw_hack(self):
fig = self.figure
fig.canvas.draw()
fig.draw(fig.canvas.get_renderer())
fig.canvas.update()
···

View this message in context: Re: QT draw issue in 1.1.0 and PyQt4v2 missing?

Sent from the matplotlib - users mailing list archive at Nabble.com.

    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

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: Unrecognized
backend.qt4 string "PyQt4v2": valid strings are ['PySide', 'PyQt4']
"%s"\n\t%s' % (val, cnt, line, fname, msg))
------------------------------------------------------------------------
View this message in context: Re: QT draw issue in 1.1.0 and PyQt4v2
missing?
<http://old.nabble.com/QT-draw-issue-in-1.1.0-and-PyQt4v2-missing--tp32676093p32680414.html>
Sent from the matplotlib - users mailing list archive
<http://old.nabble.com/matplotlib---users-f2906.html> at Nabble.com.

------------------------------------------------------------------------------
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

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Thanks for the comprehensive explanation.

So it would seem it's really only the
http://matplotlib.sourceforge.net/users/whats_new.html page that is
misleading on this.

Many thanks!

···


View this message in context: http://old.nabble.com/QT-draw-issue-in-1.1.0-and-PyQt4v2-missing--tp32676093p32680797.html
Sent from the matplotlib - users mailing list archive at Nabble.com.