Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Qt4 save dialog not functional on CentOS-5 #1126

Closed
taldcroft opened this Issue · 12 comments

4 participants

@taldcroft

After opening a plot window using the Qt4 backend and then trying to save the plot using the plot window Save button, a file dialog window appears for just a flash and then disappears. All other window functionality works as expected.

@fheday earlier reported seeing the same behaviour in macos x Lion (Python 2.7.2, matplotlib 1.1.0, Qt 4.7.4+quartz, macports) in issue #238.

I'm running on linux x64_64 with CentOS-5, using ActiveState Python and Qt4 / PyQt4 built from source.

basedirlist is: ['/usr/local', '/usr']
============================================================================
BUILDING MATPLOTLIB
            matplotlib: 1.2.x
                python: 2.7.1 (r271:86832, Feb  7 2011, 11:30:54)  [GCC
                        4.0.2 20051125 (Red Hat 4.0.2-8)]
              platform: linux2

REQUIRED DEPENDENCIES
                 numpy: 1.6.2
             freetype2: 9.10.3

OPTIONAL BACKEND DEPENDENCIES
                libpng: 1.2.10
               Tkinter: Tkinter: 81008, Tk: 8.5, Tcl: 8.5
                        * Guessing the library and include directories for
                        * Tcl and Tk because the tclConfig.sh and
                        * tkConfig.sh could not be found and/or parsed.
                  Gtk+: gtk+: 2.18.3, glib: 2.22.2, pygtk: 2.16.0,
                        pygobject: 2.20.0
       Mac OS X native: no
                    Qt: no
                   Qt4: Qt: 4.8.0, PyQt4: 4.9
                PySide: no
                 Cairo: 1.8.8

OPTIONAL DATE/TIMEZONE DEPENDENCIES
              datetime: present, version unknown
              dateutil: 1.5
                  pytz: 2010o

OPTIONAL USETEX DEPENDENCIES
                dvipng: 1.5
           ghostscript: 8.70
                 latex: 3.141592
               pdftops: 3.00
@mdboom
Owner

Strange. I can't reproduce on Fedora 17 with the following:


============================================================================
BUILDING MATPLOTLIB
            matplotlib: 1.2.x
                python: 2.7.3 (default, Jul 24 2012, 10:05:38)  [GCC 4.7.0
                        20120507 (Red Hat 4.7.0-5)]
              platform: linux2

REQUIRED DEPENDENCIES
                 numpy: 1.7.0.dev-e022a61
             freetype2: 14.0.8

OPTIONAL BACKEND DEPENDENCIES
                libpng: 1.5.10
               Tkinter: Tkinter: 81008, Tk: 8.5, Tcl: 8.5
                        * Guessing the library and include directories for
                        * Tcl and Tk because the tclConfig.sh and
                        * tkConfig.sh could not be found and/or parsed.
                  Gtk+: gtk+: 2.24.11, glib: 2.32.4, pygtk: 2.24.0,
                        pygobject: 2.28.6
       Mac OS X native: no
                    Qt: no
                   Qt4: Qt: 4.8.1, PyQt4: 4.9.1
                PySide: Qt: 4.8.2, PySide: 1.1.0
                 Cairo: 1.8.10

OPTIONAL DATE/TIMEZONE DEPENDENCIES
              dateutil: 1.5
                  pytz: 2012d

OPTIONAL USETEX DEPENDENCIES
                dvipng: 1.14
           ghostscript: 9.05
                 latex: 3.1415926
               pdftops: 0.18.4

[Edit setup.cfg to suppress the above messages]
============================================================================

Are there any exceptions printed at the console or anything?

@taldcroft

No exceptions or other indication of a problem is seen at the console. Is there a debug mode that could help?

CentOS-5 / RHEL5 is just really ancient and maybe there is some buried library conflict. This isn't really a high-priority issue from my perspective since I usually use plt.savefig() anyway.

@efiring
Owner

I see exactly this problem on OS X 10.7, pyqt 4.9.4 (installed via homebrew), qt 4.8.2 (also homebrew), python.org python 2.7.3. I don't see it on Xubuntu 12.04.

I see it only when using ipython --pylab=qt; if I use plain ipython and manually specify the backend, the file save works normally.

Edited: @fperez, any idea why this problem might be triggered by --pylab=qt on OSX? I haven't looked at the ipython mailing lists recently.

@mdboom
Owner

Using @efiring's instructions, I can confirm this on Fedora 17.

@mdboom
Owner

I'm not sure what's happening here, but it appears to be related to the inputhook that ipython installs. I tried a git bisect on ipython and came up with this commit at which it first fails: ipython/ipython@76f9a74. The commit message suggests that there is something fishy about PyQt4's own eventloop and this is a workaround, but perhaps the workaround has this unintended side effect.

Interestingly, after an unplanned reboot just now, I can no longer reproduce the bug, either with ipython master or 76f9a74750ec, so I'm not sure what happened. I'm a little concerned it's timing-related, and this is going to be really tricky to track down.

@taldcroft

Interesting. ipython --pylab=qt fails for me 100% of the time. But I can import pylab and the save dialog works:

% ipython

from pylab import *
plot()
# Press save button: SUCCESS with Qt4

I have Qt4 as my default backend. So the issue is somewhere in the processing associated with the --pylab command line switch.

@efiring
Owner

@taldcroft, yes, that is what @mdboom noted: it is --pylab that causes ipython to replace the inputhook. Plain ipython, without --pylab, leaves the qt4 inputhook alone.

@mdboom
Owner

Another useful data point might be comparing IPython at commit a76179351bccc80fa7f19571bed0e340e05f7a08 (i.e. one before the possible breakage in the inputhook) to master and see if that resolves the issue. If that happens for you, I'd be comfortable going to IPython with a bug report. It's also not clear to me if the PyQt version affects this -- we all seem to be running more or less the same. Trying PySide might be a useful data point as well.

@taldcroft

I can confirm that the save dialog works fine on CentOS with IPython commit a761793, but fails starting from the 76f9a747 commit. It also fails for the current master HEAD 011222a.

@bfroehle

I have a pull request open which might address this issue. See ipython/ipython#2294.

@mdboom
Owner

@taldcroft: Can you check @bfroehle's PR? Unfortunately, I've inexplicably fixed this issue on my machine and can no longer reproduce it.

@mdboom
Owner

This has been fixed upstream in IPython. Closing.

@mdboom mdboom closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.