Bug 497838

Hi - can you please clarify if what you're requesting is:

* Something that would detect that an application *would* become unresponsive if it were attempted to be put in focus, and summon kwin_killer_helper even if the user doesn't try to interact with the application?
* The ability to edit the killPingTimeout mentioned in https://blog.broulik.de/2023/11/freezing-in-style/ ?
* That kwin_killer_helper have a user-exposed option to not ask, and just automatically terminate applications when its timeout is triggered?

Or something distinct from those?

Thanks,

(In reply to John Kizer from comment #1)
> Hi - can you please clarify if what you're requesting is:
> 
> * Something that would detect that an application *would* become
> unresponsive if it were attempted to be put in focus, and summon
> kwin_killer_helper even if the user doesn't try to interact with the
> application?
> * The ability to edit the killPingTimeout mentioned in
> https://blog.broulik.de/2023/11/freezing-in-style/ ?
> * That kwin_killer_helper have a user-exposed option to not ask, and just
> automatically terminate applications when its timeout is triggered?
> 
> Or something distinct from those?
> 
> Thanks,

Probably the third one. The app becomes gray, it remains like that for 3/5 minutes, then the system kills it.

Updating the title to clarify, thanks.

I will defer to KWin developers on whether it's a desired wishlist item, as the potential for users to create unpredictable and very undesirable results seems high, but I wouldn't necessarily have the best perspective there.

(In reply to John Kizer from comment #3)
> Updating the title to clarify, thanks.
> 
> I will defer to KWin developers on whether it's a desired wishlist item, as
> the potential for users to create unpredictable and very undesirable results
> seems high, but I wouldn't necessarily have the best perspective there.

Making the lowest time limit allowed 3/5 minutes should mitigate some of these issues, I imagine.

> The app becomes gray, it remains like that for 3/5 minutes, then the system kills it
No user is going to wait 3-5 minutes if an app is hung or the whole system is unresponsive. They're going to manually kill the app via the dialog, or forcibly restart the machine by holding down the power button. As such, I imagine if we did implement it, almost no one would ever encounter it at all. I don't think so, sorry.

(In reply to Nate Graham from comment #5)
> > The app becomes gray, it remains like that for 3/5 minutes, then the system kills it
> No user is going to wait 3-5 minutes if an app is hung or the whole system
> is unresponsive. They're going to manually kill the app via the dialog, or
> forcibly restart the machine by holding down the power button. As such, I
> imagine if we did implement it, almost no one would ever encounter it at
> all. I don't think so, sorry.

It would help if the user were in the middle of writing, editing, or anything important that didn't have auto-save at the time of freezing.
I guess I'll think of another approach to this issue.

In general it's best to report issues rather than suggesting solutions to them. See https://community.kde.org/Get_Involved/Issue_Reporting#Proposing_a_solution

(In reply to Nate Graham from comment #7)
> In general it's best to report issues rather than suggesting solutions to
> them. See
> https://community.kde.org/Get_Involved/Issue_Reporting#Proposing_a_solution

If I can recall the issue was that compiling cosmic-epoch with paru was freezing the whole system to the point I could see in the clock that it took about 15 seconds to show the next frame. Now it's not possible for me to reproduce it because cosmic-epoch is now cosmic-session and it doesn't slow down the system anymore.

It sounds like the system was getting starved of memory. A kernel-level OOM killer is a more appropriate solution at the right level of the stack if you're comfortable with apps getting killed in such a situation. Many distros ship with one out of the box. Arch being a DIY distro, you'll need to set this up for yourself if you want it there.

(In reply to Nate Graham from comment #5)
> > The app becomes gray, it remains like that for 3/5 minutes, then the system kills it
> No user is going to wait 3-5 minutes if an app is hung or the whole system
> is unresponsive. They're going to manually kill the app via the dialog, or
> forcibly restart the machine by holding down the power button. As such, I
> imagine if we did implement it, almost no one would ever encounter it at
> all. I don't think so, sorry.

What if instead it was a "Press Alt+F4 and wait 30 seconds to close the focused unresponsive gray window"?
It would make the users save a lot of time and it would properly respect their voluntary decision to Alt+F4 an app.

Alt+F4 is a compositor-level shortcut; it *should* work for hung apps to either close them or else quickly trigger the kill dialog. If it doesn't, that's the bug that should be fixed.

(In reply to Nate Graham from comment #11)
> Alt+F4 is a compositor-level shortcut; it *should* work for hung apps to
> either close them or else quickly trigger the kill dialog. If it doesn't,
> that's the bug that should be fixed.

If I recall, the function that kills apps requires the user to aim a skull with their mouse, which is terrible if you have a small unresponsive window. The kill dialog also requires mouse movement, right?

Does the kill dialog have a timer in case user does nothing?
If it doesn't, can't I file an bug requesting a 30 second timer to be implemented into the kill dialog?

(In reply to Fernando M. Muniz from comment #13)
> Does the kill dialog have a timer in case user does nothing?
> If it doesn't, can't I file an bug requesting a 30 second timer to be
> implemented into the kill dialog?

https://bugs.kde.org/show_bug.cgi?id=498510