PyQt5 closeEvent reimplementation

[JonB]

@user4592357
I really don't understand what it is you want to happen or not happen when user clicks Ctrl+C. But have you looked at:

• https://stackoverflow.com/questions/4938723/what-is-the-correct-way-to-make-my-pyqt-application-quit-when-killed-from-the-co
• https://stackoverflow.com/questions/5160577/ctrl-c-doesnt-work-with-pyqt
• the other various pages out there for handling Ctrl+C from PyQt5

?

[user4592357]

@JonB

i've tried to do what's said in the 2nd link, namely:

import signal
signal.signal(signal.SIGINT, signal.SIG_DFL)

it kinda works. i mean, when i do "ctrl+c" then close the window with X, i don't get KeyboardInterrupt execption.
it gives this error though when pressing ctrl+c: QObject::~QObject: Timers cannot be stopped from another thread
i don't understand how and why this works though (please explain!). i read that SIG_DFL is the default handler but still no idea.

what i want is the application to exit gracefully when Ctrl+C is pressed. but i guess from the explanation of the article that it's not possible to interrupt python while qt loop is running

[JonB]

@user4592357

This is not my area, so I can only give you some ideas/explanations. I'm newish to Qt & Python/PyQt. My background is more pure C stuff.

When Ctrl+C is pressed, a signal is raised, "interrupt signal", SIGINT. The signal function has 3 possible "dispositions" which can be specified for SIGINT:

• SIG_DFL: Default, which is terminate the program.
• SIG_IGN: Ignore, do nothing, treat it just like a key press.
• Some function: call that function.

Reading the posts, the problem is that signal is passed to the Python interpreter which is running your Python code, but that interpreter is not executing while you are in a Qt loop such as the standard sys.exit(app.exec_()) a Qt program is usually sitting in. Hence all the shenanigan solutions, none of which work perfectly.

My own thought would be: why are you/do you need to react to Ctrl+C at all? Given that with Qt you have a GUI program with a window, it's not "normal" to have anywhere to press Ctrl+C in the first place. When you run, say, Notepad, you don't have a terminal to press anything in anyway. You just use the GUI to close the main window, or similar. there is no "asynchronous interrupt signal". I don't know about your "from integrated terminal (I'm using visual studio code)". When I start my Python/PyQt application from a terminal (Linux), pressing Ctrl+C in that launching terminal does nothing (other than echo ^C in the terminal window), it does not exit my application.

Furthermore, there is no reason your Python app should be launched from a terminal in the first place. Since it's a GUI application, aren't you going to provide for it being launched from a desktop icon? Then there will be no invoking terminal for anyone to press Ctrl+C in the first place.

I'd be tempted to turn Ctrl+C signal handling off (signal.signal(signal.SIGINT, signal.SIG_IGN)), and if you really want to recognise and act on Ctrl+C do it purely in a Qt key press event like https://stackoverflow.com/a/24252234/489865. That would mean Ctrl+C is only handled as & when it's pressed in the Qt application window and Qt is prepared to handle the event.

Otherwise did you have a try of https://stackoverflow.com/a/11705366/489865 ? Ugly but might work acceptably.

Finally, if none of these is acceptable to you this is a question you might like to raise by joining up at https://www.riverbankcomputing.com/mailman/listinfo/pyqt. Since your question is about PyQt handling, the guys there are the absolute experts on what can or cannot be done from Python/PyQt, and I'm sure they'd tell you if there are any good alternatives.

Let us know!

[user4592357]

@JonB

thanks for a good answer. i've tried many "solutions" (including ones in the mentioned links) but none of works as a expected. now i understand why.

and you're right, since i'm going to deploy the application sooner or later, there is no need to worry about such things

[user4592357]

btw, is there a way to pass command line arguments to a deployed app (sounds surreal but im asking)?

[SGaist]

Do you mean like QCommandLineParser ? Or Python's argparse module ?

[JonB]

@user4592357
What do you mean about deployed app & argument passing? If by any chance you mean can you pass arguments once the app is launched from the desktop via a shortcut, then yes. In general, your PyQt app's __main__ sees sys.argv like normal.

[user4592357]

@JonB,
yes that's what i meant. i'll try that.

@SGaist,
should i reimplement __del__() for calling __write_settings()? the book which i use as a reference says that, "in all X classes presented in the book, none reimplements it"

[SGaist]

Can you give the reference ?

[user4592357]

@SGaist
https://fatima-python.wikispaces.com/file/view/Rapid+GUI+Programming+with+Python+and+Qt.pdf
page 79 (book page, pdf page is 93)

[JonB]

@user4592357
I wouldn't put anything as complicated as saving settings in a destructor. Your closeEvent() sounded right for this. Why are we suddenly discussing __del__()?

[SGaist]

Because of this:

@SGaist said in PyQt5 closeEvent reimplementation:

Personally, I usually write down settings in the destructor of a class rather than close event.

That's what I do in C++.

[JonB]

@SGaist
Ohhh, didn't see that.

Umm, far be it for me to disagree, but personally I wouldn't. I thought destructors were supposed to be cheap and have no side-effects. So many things can happen when saving settings. I wouldn't do it in C# FWIW, and I wouldn't do it in Python. (I also would not load settings in __init__().)

[user4592357]

@SGaist
what about the book's statement?

[SGaist]

In the python case, that's indeed something debatable. Most of the time, people don't need to implement __del__.

What I would do is to store the settings once you close the corresponding dialog so that you avoid the trouble you had with the unintended interruption you have (unless it's done while the dialog is open).

In the extreme case, you can even save you settings on modification if you have an "apply immediately" without cancel style of application preferences.