| Summary: | Add a 30 seconds timer to "Kill Dialog" to better deal with Alt+F4'ed unresponsive apps freezing the system | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Fernando M. Muniz <fernandommuniz> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | fanzhuyifan, nate |
| Priority: | NOR | ||
| Version First Reported In: | 6.2.5 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | This window needs a 30 seconds timer. | ||
Can you envision how would this handle the case where an unresponsive app becomes responsive again and has unsaved data you don't want lost if it gets killed automatically? (In reply to Nate Graham from comment #1) > Can you envision how would this handle the case where an unresponsive app > becomes responsive again and has unsaved data you don't want lost if it gets > killed automatically? If the user has pressed Alt+F4 he expects the app to be closed. (In reply to Fernando M. Muniz from comment #2) > (In reply to Nate Graham from comment #1) > > Can you envision how would this handle the case where an unresponsive app > > becomes responsive again and has unsaved data you don't want lost if it gets > > killed automatically? > > If the user has pressed Alt+F4 he expects the app to be closed. However, if the timer hasn't reached 0 and the app became responsive again, then it should cancel the timer, making it safer than what we currently have when Alt+F4'ing responsive apps! Only when invoked by Alf+F4 (or the close button, presumably)? That could work. (In reply to Fernando M. Muniz from comment #2) > (In reply to Nate Graham from comment #1) > > Can you envision how would this handle the case where an unresponsive app > > becomes responsive again and has unsaved data you don't want lost if it gets > > killed automatically? > > If the user has pressed Alt+F4 he expects the app to be closed. IMO if users press Alt+F4, they expect the app to gracefully close, *without losing data*. Implementing this would make closing apps slightly more dangerous -- if I click close or press alt+f4, and then temporarily leave or is otherwise unable to interact with the kill dialog, I might lose data if the app is unresponsive for more than 30 seconds. IMO having default options (in this case, inaction) that potentially causes lost data is not good. Alternately, how feasible is it to boost the responsiveness of the kill dialog under heavy system load? I recall the force quit dialog on macos being pretty responsive even under heavy system load. (In reply to fanzhuyifan from comment #5) > Alternately, how feasible is it to boost the responsiveness of the kill > dialog under heavy system load? I recall the force quit dialog on macos > being pretty responsive even under heavy system load. Plasma's "core" being protected RAM/CPU wise from unresponsive apps sounds possible but very difficult to implement. (Not a dev) Maybe a metabug should be created to do the Apple/MacOS approach for all important system parts instead? (crash handler, item deletion confirmation, system monitor, shutdown buttons) I think Bug 502776 is likely has the same problem of responsiveness. |
Created attachment 177273 [details] This window needs a 30 seconds timer. In situations where an unreponsive app is slowlying down the system, it's very difficult to interact with the kill dialog after the app did not respond to the Alt+F4. a 30 seconds countdown should be time enough to assume that users can't interact with the kill dialog, and kill the app.