[IPython-dev] Qt api selection re. ipython and matplotlib
Darren Dale
dsdale24 at gmail.com
Wed Jul 6 08:33:55 EDT 2011
On Wed, Jul 6, 2011 at 4:15 AM, Eric Firing <efiring at hawaii.edu> wrote:
> On 07/05/2011 08:06 PM, MinRK wrote:
>> I didn't mean that it would ask matplotlib what PyQt API to use, only
>> whether to use PyQt or PySide. Eric issues a PR that suggested such
>> an option was incoming.
>>
>> I've issued another pull request based on Eric's that handles various
>> cases, and also tries to explain some of this mess in the docs as you
>> suggested.
>>
>> PyQt4 unmolested will happen most of the time, but PySide when
>> requested will still be used, and PySide will be a fallback for
>> ``gui=qt`` if PyQt isn't installed.
>>
>> The *only* way PyQt4 will be using v2 is if the ETS env variable is
>> set as QT_API=pyqt, *and* matplotlib had nothing to say about PyQt vs
>> PySide (matplotlib being<= 1.0.1 also prevents PyQt with v2). If we
>> gathered from matplotlib that we should use PyQt, it will not be
>> patched to v2.
>>
>> This places matplotlib / PyQt v1 code at the highest priority, but
>> also allows ETS, and code that uses modern interfaces, to work via
>> QT_API.
>
> Darren et al.,
>
> Is all this good from your mpl/qt standpoint? We could make mpl pay
> attention to the ETS QT_API environment variable, if present, while
> retaining the rcParam. For example, QT_API could simply override the
> rcParam, with the additional effect of forcing v2 in the PyQt4 case. In
> other words, if QT_API is defined, we would follow the original ETS
> strategy; otherwise the rcParams strategy as in my last mpl pull request.
I think this may be necessary. The error message you originally
reported came from IPython, which complained that it was trying to set
the api but could not, presumably because matplotlib had already
imported PyQt4. The api needs to be set before any PyQt4 imports.
> I think that although this is a bit more complicated, and would require one
> more iteration on the ipython side as well as on the mpl side, it might last
> longer as a way to handle just about all situations, including mpl mixed
> with ETS things.
I think you are probably right.
Darren
More information about the IPython-dev
mailing list