@Chris-Kawa Thanks, it works !

@kshegunov
Thank you for confirming that the principle is correct. I am presently debugging and discovering that the Quit button has nothing to do with the self.actionQuit = QtWidgets.QAction("Quit", self), and has some overridden code elsewhere such that it is doing its own QtWidgets.QApplication.exit() and is not connected to self.close() and hence self.closeEvent() at all :( Hence the lack of behaviour.

I will complete this post in a few minutes, having solved the issue for me. Thank you for your help.

EDIT: So the code I inherited declared an actionQuit and connected to a callback (just to fool me), but never actually created it in the menu via self.toolbar.addAction(self.actionQuit). The Quit button had code in a different module(!) to just do QtWidgets.QApplication.exit(), no "closing" at all. Once I traced this down I have made it call close() on main window instead and now all is well with that invoking closeEvent().

Not my fault existing code is a labyrinthine mess, and I'm new to Qt & Python! Thanks for all help.

@CN_Simo

您是在MainWindow的close事件中，发射信号进行清理关闭工作的。

Qt signal and slot确实很方便。 可是有时候也会造成一些不必要的麻烦。很多时候，也可以传递对象的指针，直接在对应的地方调用对象的函数即可。

You're welcome !

As for marking the thread as solved, you can now use the "Topic Tool" button, it will keep the title clean.

Also, while browsing the forum, please consider up-voting answers that helped you, that will make them easier to find for other forum users :)

My understanding of self.close() got the better of me. self.close() returns self.reject(). That was what I did not understand. self.done(1) would also work, but I think self.accept() is clearer in this case.

Thank you QT-static-prgm.

Well ... someone in a corporate environment here [1] really suffering from this bug after upgrading to openSUSE Leap 42.1 which ships with Plasma 5. Considering openSUSE Leap and SUSE Linux Enterprise Server are now so tightly coupled in development I suspect this bug will start to affect more and more users.

I would like to add that sometimes it's not just an extra warning, but actually blocks the UI.

Running strace on kwrite opening a file from a NFSv4 drive results in the following messages:

open("/NFSv4mount/home/user/.config/kwriterc.lock", O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0644) = 9
fcntl(9, F_SETFD, FD_CLOEXEC) = 0
flock(9, LOCK_EX|LOCK_NB) = 0
fcntl(9, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = -1 EAGAIN (Resource temporarily unavailable)
write(2, "setNativeLocks failed: Resource "..., 56setNativeLocks failed: Resource temporarily unavailable
) = 56
write(9, "24895\nkwrite\nPC-123456\n", 23) = 23
open("/NFSv4mount/home/user/.config/kwriterc.lock", O_RDONLY|O_CLOEXEC) = 12
fcntl(12, F_SETFD, FD_CLOEXEC) = 0
fstat(12, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
fstat(12, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
read(12, "29337\nkwrite\nPC-123456\n", 16384) = 23
read(12, "", 16361) = 0
close(12) = 0
uname({sysname="Linux", nodename="PC-123456", ...}) = 0
kill(29337, SIG_0) = -1 ESRCH (No such process)
open("/NFSv4mount/home/user/.config/kwriterc.lock", O_WRONLY|O_CLOEXEC) = 12
fcntl(12, F_SETFD, FD_CLOEXEC) = 0
flock(12, LOCK_EX|LOCK_NB) = 0
fcntl(12, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = -1 EAGAIN (Resource temporarily unavailable)
close(12) = 0
close(9) = 0
unlink("/NFSv4mount/home/user/.config/kwriterc.lock") = 0
nanosleep({6, 400000000}, 0x7ffd3a249730) = 0

(the nanosleep timer just increases, meanwhile the kwrite window stays "blank" (actually whatever the background of the window was when it was started)).

If I intervene and remove this file kwrite immediately returns and shows the file. And in subsequent starts the file opens immediately.

Perhaps a workaround would be to move my .config directory back to local disk and place a symlink in my home folder to this on disk location.

Relevant bug report:
https://bugreports.qt.io/browse/QTBUG-43454

===
My corporate environment, for those interested:
[1] Using sssd.conf: services = nss, pam, autofs
Using ldap to login, automount to mount a NFSv4 Kerberized mount.