[openbox] [RELEASE] Openbox 3.4.6 and ObConf 2.0.3

[Dana Jansens]

2008/2/2 George De Bruin <sndchaser at gmail.com>:
> Dana Jansens wrote:
>
>  >     * Application windows which support the appropriate protocols will
>  > now show [Not Responding] in their titlebars when the application has
>  > frozen up. By closing the window while the [Not Responding] message is
>  > visible, Openbox will kill the window's process, allowing you to kill
>  > frozen applications without dropping to the command line. If the
>  > window still won't close after the first try, a further close attempt
>  > will use kill -9.
>  As a feature, while this sounds good, it's not the best way to handle
>  this situation.  Signal 9 (KILL) should only be used as a last resort as
>  it doesn't give the application any chance to do a graceful exit, and
>  will result in lost data if there are files open.  There are quite a few
>  other signals that should be tried before KILL: INT, QUIT, ABRT, TERM,
>  and STOP should definitely all be tried before KILL as the response to
>  them may allow a clean exit of the application.  In some cases, CONT,
>  USR1 and USR2 may even be of benefit, but it is definitely a little less
>  certain what will happen.
>
>  At this point, from the way your description is written, it does sound
>  like you use TERM first, then resort to KILL.  Personally, I would
>  prefer to see OpenBox trying: TERM, INT, QUIT, ABRT, STOP, and finally
>  KILL.  Even if the application doesn't terminate until it is killed,
>  there is a much better chance that it might does some kind of cleanup in
>  response to one of the other signals.

I see your point, however clicking the close button 7 times seems to
be a bit of an unreasonable requirement, so I don't know..  How many
apps really don't respond to TERM but respond to other signals?  I
don't image very many.