force quit for stubborn apps

[the ringmaster]

I would like to see some sort of force quit funtionality added to Haiku's window manager. Some applications, if they don't crash, will lock up and there really isn't a way that I know of to quit them when they do this.

thanks

[anevilyak]

You can actually do that with things like ProcessController.

[koki]

This functionality already exists: click on the locked up application in the Deskbar while pressing press shift-ctrl-alt, and the app will be killed.

[the ringmaster]

why can't we have it where when you are clicking on the close buttons and nothing happen. Haiku (or the program that is actually doing the quitting) will automatically force the shutdown of the app(s).

[emitrax]

I'm in favor of adding such as functionality, like they do in GNOME, although applications should never lock up.

[anevilyak]

It wouldn't be wise to do that without asking, some apps might take some time to shutdown or whatnot, i.e. if they have to commit back large amounts of data, close network connections or whatnot, so imo this should only be done if the user specifically asks for it. That having been said there's already several ways to do this, I don't see the point in adding another one.

[emitrax]

In GNOME, if an application does not respond and the user keep asking to close the application, the WM pops up a little window and ask esplicitly to kill the application with all the risk of loosing data.

I think this way of doing thing is better, and easier to discover for the user, than pressing 3 bottons + a mouse click. How would I know this functionality is already there?

[anevilyak]

I already mentioned ProcessController also, I'm well aware of how gnome behaves.

[mmlr]

There are already four ways of doing that: ProcessController (installed by default in the Deskbar), the "vulcan death grip" mentioned by Koki, through the Team Monitor brought up by ctrl-alt-delete and by kill in the Terminal. There might be even more ways I forgot to mention. So can we please refrain from adding yet another method? I take it from your mention of "window manager" that you come from a Unix/Linux background where this feature might be implemented like you outlined. In cases like this though I really find it more appropriate to invest the little time it takes and learn how to do it on a different system, instead of modifying the system to become more similar to something else. Haiku is not Unix/Linux, there is no separate window manager or the like and I don't really see the point of just copying the behaviour of another system if the features are already there.

[axeld]

I think we should make the team monitor more accessible instead, maybe an additional Deskbar entry could help with that.

[emitrax]

It's not about making Haiku behave like any other linux based OS, it's about making this operation as easy as possible and IMHO the way GNOME handles this, from an user point of view, it is simple the best one.

[koki]

Being able to Kill a non-responsive app clicking on the close button sounds very logical.

Are there any technical issues for not wanting to do it this way, or is it a matter of wanting to stick to BeOS behavior for R1?

If the latter, then this could be put on the list of desired features for post R1 releases.

[diver]

I would like to have this feature too, it's seems logical how gnome handles it. I faced too much BeOS apps which will not close (or rather leave deskbar entry) while i would like it to close cleanly.

[anevilyak]

The problem I have with that approach that I've quite often run into on *nix is that it's very difficult to accurately guess if an app is in fact unresponsive or simply taking some time to complete its shutdown tasks. Especially if the system is under load, having to pull stuff out of swap or whatnot, I've often had it suggest I kill an app that's in the middle of saving a document, where if I'd actually listen to it and click kill I'd probably lose/corrupt my data. Hence I'd prefer this to be more of a deliberate action on the part of the user than automatically suggested.

[koki]

The problem I have with that approach that I've quite often run into on *nix is that it's very difficult to accurately guess if an app is in fact unresponsive or simply taking some time to complete its shutdown tasks...

Lack of responsiveness due to an app being busy is very rare in BeOS; it also sort of goes against the Haiku-has-no-hour-glass responsiveness that we preach. So I am not sure this argument holds ground.

Strictly from a user POV, clicking on the close button shows an unequivocal intent by the user to terminate the app. Whether this is because the user is done using the app or due to the app becoming unresponsive, it is not relevant.

But if you want to avoid situations such as the one you describe, how is using the Team Monitor to kill the app different from clicking on the close button? Does the Team Monitor provide a visual clue of unresponsive apps to the user (I don't remember)?

[meanwhile]

@Koki: From memory, the Team Monitor shows the unresponsive app in red vs. the responsive apps in black from the active apps list. If this particular app is then selected from the list, the Team Monitor tells the user about its suspicion of the app "seeming to behave badly".

[humdinger]

IMO, I'd be best to merge ProcessController and TeamMonitor, i.e. CTRL+ALT+DEL invokes ProcessController with a windowed interface and the features of TeamMonitor (Kill, Reboot, Restart Desktop, marking unresponsive teams red etc.). Maybe with tabbed views and also the ActivityMonitor replicant integrated. And, why not if it's possible, invoke this new Über-TeamController when a QuitRequested doesn't respond in a reasonable time.

[stippi]

I am with emitrax and koki on this one. It should be possible to get it working in a reliable way (time out in Deskbar for reply message, time outs in window quit loop in BApplication, some magic in app_server when closing windows, etc). Misbehaving apps do happen and the hidden features to kill them are not helpful to non-techy users. If an app does take a long time to close, it should anticipate this case and behave in a way that does not irritate the user. Either it closes it's windows and keeps saving, or better yet, it needs to display a progress bar for long lasting operations. The user is not to be irritated, no matter what.

[axeld]

I think this is happening so rarely that I don't feel it's necessary to add a special solution to Haiku. As a novice user, it's probably easier to deal with a minimized app than to decide whether or not an app should be killed.

I would rather argue that applications that tend to deadlock should be fixed.

FYI OS X does not have any other way to kill an app besides the team monitor. Besides for Finder, I never had to use it there, either. On BeOS, I usually only need it for Firefox. On Ubuntu and Windows (which both have that feature), I have to use it quite often, though. Let's please just not get there :-)

[stippi]

I am pretty sure that no one disagrees that effort should be put into applications for them to always behave well. But this is about how "the computer" behaves in the case something goes wrong. And this separates good software from ok software. Somewhere, sometimes, something will go wrong which someone didn't anticipate in his software, and for that case is this feature. It's an OS versus applications thing, the OS is our job while applications may not be in our control. If some proposed solution does not work in some case, that's one thing, but I think the feature itself is still desirable and maybe there is a way to make it work reliably. IMHO we should think about it and keep this ticket.

[andreasf]

Replying to axeld:

FYI OS X does not have any other way to kill an app besides the team monitor.

Actually it does detect that an app has become unresponsive and then offers "Sofort beenden" from its dock menu. I had to use it quite often for Mail when I lost my 802.11 connection at university. ;)

[BeOSR]

Clicking deskbar entry with Vulcan death grip (while holding down right ctrl-alt-shift keys) doesn't kill stray app any longer, only hides all its windows. Not good, as this was a very effective way of getting rid of a crashed or unresponsive app. This started somewhere around R29800. If it's intentional, I don't like it.

[waddlesplash]

No, it wasn't intentional. Vulcan death grip should still work just as before...

[waddlesplash]

Reverting earlier milestone change

[pulkomandy]

Does not need to be in R1.