persistent unresponsive window (python 2.7.8)

[jeremygray]

The launcher demo works fine, but when I try to use the functions as a library, a GUI pops up and returns the value I set, but does not then go away. The window just becomes unresponsive and cannot be canceled or dismissed.

>>> import easygui_qt.easygui_qt as ez
>>> ez.get_int()
[warning message here: "modalSession has been exited prematurely blah blah", don't think its relevant but it might be; I get that with the launcher demo, which works anyway] 
1
>>> 

Same behavior from a script or interactive python session.

[aroberge]

That's going to be a tough one to debug ... it just works here, when done this way - with both Python 3.4 and 2.7.9 .

Assuming it was working yesterday, other than removing the decorator, the changes that have been made as far as I remember are:

1. addition of a new flag (QtCore.Qt.WindowStaysOnTopHint)
2. inheriting from a custom dialog which uses self.show() and self.raise_() somewhat along the lines of what you suggested. Perhaps you can see if changing back any of these would have the desired effect?

[aroberge]

Another possible option: just before app.quit(), add dialog.destroy(). It doesn't seem to do anything here (so no problems...) but perhaps it might solve yours?

[jeremygray]

dialog.destroy() did not do the trick. Worth keeping in mind though. That kind of thing was needed with some wx-python dialogs on Mac to avoid a memory leak, not sure if its fixed now.

Starting at cd8538e9fa ("cleaning up the code and addressing (partly?)..."), get_float() (or get_int) pops up two windows at once: "Enter a value" is hidden underneath, with "Choose a number" on top. Choosing a number sends away that window, but not the "Enter a value" one, which remains until python exits.

I suspect it has to do with the class VisibleInputDialog, which is new in that commit. If I comment out the .show() and .raise_() lines, I don't get the double windows (and don't get the right one being brought to the top either). This is your second suggestion above.

[aroberge]

I introduced VisibleInputDialog as a way to avoid repeating dialog.show() and dialog.raise() every time and possibly add new default capabilities to all such widgets. If you find out that removing it and using a standard QInputDialog followed by explicitly calling show() and raise(), then I'd certainly be happy to use that instead.

[jeremygray]

Its exactly the same when moving the .show() and .raise_() inside the function (same as doing so inside the class). I'll have to read up more about this. I suspect its mac-specific behavior somehow.