Am 28.08.2012, 01:56 Uhr, schrieb Daniel Nicoletti <dantt...@gmail.com>:
a) add an eventfilter on the application to suck all input events (for
that
window) so clicking apply etc. isn't possible and the window also will
not
receive close events
b) intercept sigterm and reject it as long as you're waiting for the
async
return
The main problem won't be fixed with this, a kquitapp will still crash
the application.
Is kquitapp really the main problem?
You can hook onto aboutToQuit() and ensure to get rid of the external
depends (SIGTERM the password dialog?) but i don't thinks it's possible to
block exit(0) calls.
(tho maybe b could work but to me seems quite complex...)
No. exit(0) does not raise(SIGTERM) or any signal - unfortunately (why
kquitapp and exporting exit to dbus - let's say i'd not have done that)
Can you point to the troublesome code?
Atm i'm frankly not even sure whether the client or the password dialog
should manage this (latter could do hardly more than either grab input and
ensure it's not passed to the client or sigstop the client - but that does
not prevent X11 event processing, they're queued and the client will
process them as long as the queue did not get flushwiped on SIGCONT) -
also this means that the client won't be able to process anything else
interim (including dbus calls) - until it's continued, of course.
Cheers,
Thomas
