spyder-ide / spyder

Official repository for Spyder - The Scientific Python Development Environment
https://www.spyder-ide.org
MIT License
8.32k stars 1.61k forks source link

New release dialog is un-clickable #3609

Closed bryanSME closed 8 years ago

bryanSME commented 8 years ago

Description

What steps will reproduce the problem?

  1. Install the latest (windows) anaconda2 v4.2.9 with Spyder v3.0.0
  2. Run Spyder.exe

What is the expected output? What do you see instead? The "Spyder 3.0.1 is available!" QT pop-up that appears when spyder starts is un-clickable. There are two links, "Releases", "Installation" as well as an "OK" button that all can't be clicked on. The "X" button to kill the pop-up works fine.

Please provide any additional information below Interestingly, once the menu is clicked, the "tab" button can be used to tab to the "OK" button. The text inside the pop-up can't be highlighted.
Windows10 Version 1607 (OS Build 14393.321) Radeon Driver Packaging Version 16.40.2311-160916a-307101E

Version and main components

pyflakes >=0.5.0 :  1.3.0 (OK)
pep8 >=0.6       :  1.7.0 (OK)
pygments >=2.0   :  2.1.3 (OK)
qtconsole >=4.2.0:  4.2.1 (OK)
nbconvert >=4.0  :  4.2.0 (OK)
pandas >=0.13.1  :  0.18.1 (OK)
numpy >=1.7      :  1.11.1 (OK)
sphinx >=0.6.6   :  1.4.6 (OK)
rope >=0.9.4     :  0.9.4 (OK)
jedi >=0.8.1     :  0.9.0 (OK)
matplotlib >=1.0 :  1.5.3 (OK)
sympy >=0.7.3    :  1.0 (OK)
pylint >=0.25    :  1.5.4 (OK)
ccordoba12 commented 8 years ago

Thanks for reporting. We already noticed it but we don't know why this is happening :-/

@malliwi88, could you work on this one please?

ccordoba12 commented 8 years ago

@mariacamilaremolinagutierrez, since we don't know where @malliwi88 is right now, I'm going to assign this one to you.

Please try to understand why the dialog is unclickable and solve this problem.

jnsebgosselin commented 7 years ago

While trying to emulate this functionality of Spyder in my own project, I've came with further insights about this issue and with solutions to fix it while preserving the capability to show the message box icon.

The problem This issue occurs only with PyQt5, not with PyQt4. From what I understand, I think it is due to changes in the Qt framework between Qt4 and Qt5. In Qt4, when setIcon is called, the icon is simply set to the iconLabel of the message box and only a updateSize is called on the iconLabel.

In Qt5 however, after the iconLabel icon is set, the message box layout is deleted on the Qt side and a new layout is built from scratch in a new method called setupLayout. I think this is where the problem comes from since qt is not aware of the custom checkbox we've added when rebuilding the new layout. Therefore, the old layout is still referenced by our custom checkbox and probably cannot be deleted on the python side. So somewhat, after setIcon is called, the message box ends up with 2 layouts, without any error being raised by qt. This is probably why the message box is not working afterwards. My guess is that the old layout is laid above the new one and is blocking any action to the new ones due to the modal property of the message box.

Solution This problem can be fixed in multiple ways, while still being able to show an icon on the message box. The simplest one I could comes up with is a little bit hackish, but allows to solve the issue with a minimal amount of changes to the code, while preserving backward compatibility with PyQt4. The idea is to set the Icon before our custom checkbox is added to the layout, thus preventing a call to setupLayout that messes things up. Thus, only 3-4 lines of codes needs to be added to solve the issue.

The other solution I can think of requires a little bit more modifications if backward compatibility with PyQt4 is needed. The ability to add a checkbox to a message box was added to the framework in Qt5. So we could use this new functionality to add a checkbox instead of adding our own in a custom class. This however will break backward compatibility wit PyQt4. So we would still need to use a custom class for PyQt4. So this will be harder to maintain a common code base for PyQt4 and PyQt5.

Personally, I prefer the first option. I will propose a PR soon, so you can comment and revised my proposed solution.

ccordoba12 commented 7 years ago

@jnsebgosselin, thanks a lot for tracking this down and to help us fixing it!

ccordoba12 commented 7 years ago

And I also agree that the first option is our best option, for now (i.e. until we drop PyQt4 support).