Opened 12 years ago

Last modified 3 years ago

#2542 new enhancement

force quit for stubborn apps

Reported by: the ringmaster Owned by: stippi
Priority: normal Milestone: Unscheduled
Component: User Interface Version: R1/pre-alpha1
Keywords: Cc: mdisreali@…
Blocked By: Blocking:
Platform: All


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.


Change History (26)

comment:1 by anevilyak, 12 years ago

You can actually do that with things like ProcessController.

comment:2 by koki, 12 years ago

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.

comment:3 by the ringmaster, 12 years ago

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).

comment:4 by emitrax, 12 years ago

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

comment:5 by anevilyak, 12 years ago

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.

comment:6 by emitrax, 12 years ago

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?

comment:7 by anevilyak, 12 years ago

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

comment:8 by mmlr, 12 years ago

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.

comment:9 by axeld, 12 years ago

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

comment:10 by emitrax, 12 years ago

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.

comment:11 by koki, 12 years ago

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.

comment:12 by diver, 12 years ago

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.

comment:13 by anevilyak, 12 years ago

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.

comment:14 by koki, 12 years ago

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)?

comment:15 by meanwhile, 12 years ago

@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".

comment:16 by humdinger, 12 years ago

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.

comment:17 by stippi, 12 years ago

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.

comment:18 by axeld, 12 years ago

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 :-)

comment:19 by stippi, 12 years ago

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.

in reply to:  18 comment:20 by andreasf, 12 years ago

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. ;)

comment:21 by Disreali, 11 years ago

Cc: mdisreali@… added

comment:22 by BeOSR, 11 years ago

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.

comment:23 by waddlesplash, 6 years ago

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

comment:24 by waddlesplash, 5 years ago

Milestone: R1Unscheduled

comment:25 by waddlesplash, 5 years ago

Milestone: UnscheduledR1

Reverting earlier milestone change

comment:26 by pulkomandy, 3 years ago

Milestone: R1Unscheduled

Does not need to be in R1.

Note: See TracTickets for help on using tickets.