KCM Authorization (was: Re: Review Request: print-manager on kdereview)

Daniel Nicoletti dantti12 at gmail.com
Tue Aug 28 00:56:02 BST 2012


2012/8/27 Thomas L├╝bking <thomas.luebking at gmail.com>:
> Am 27.08.2012, 22:53 Uhr, schrieb Daniel Nicoletti <dantti12 at gmail.com>:
>
>
>> So to avoid the application quiting modules that need to perform
>> async tasks like talking to polkit or installing packages (Apper),
>> they need to create an event loop so that current module accept()
>> doesn't return (if it does quit() will be called).
>>
>> So the user clicks Apply, while setting the time or doing anything
>> the user clicks to close the window, the event loop will return
>> and some stuff will be already deleted which causes the crashes...
>
>
> As far as i understood the bottomline is the task to make an external
> process fully modal to the window, yesno?
>
> Aside that the NETWM spec probably SHOULD say that modal windows must not
> receive input focus and mouse events and also not be closed, weird ideas:
> 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.
(tho maybe b could work but to me seems quite complex...)
Nested event loops brings all kinds of trouble... surely there are places where
you don't have an option, which is were you must check if the
application is quitting..
and in the KCM case only with QPointer I could do this kind of crash go away
QAppliction::isClosing() or something like that didn't do the trick
(don't recall why)...




More information about the kde-core-devel mailing list