Mail Archives: cygwin/2010/03/09/08:56:29
Andy Koppe wrote:
> Thomas Wolff:
>
>>>> In general, a GUI application started in the background, like a terminal,
>>>> should detach itself from its parent process so that it survives if the
>>>> parent is terminated.
>>>>
>>> Says who?
>>>
>> Common practice in Unix/Linux/X environments.
>>
> I've finally got round to trying to confirm this on Linux, and the
> results make me wonder what exactly you are basing this assertion on.
> Out of the terminals I tried, xterm and urxvt ignored SIGHUP, whereas
> rxvt, konsole, gnome-terminal, and lxterminal terminated. Among a
> bunch of other GUI apps, only gvim ignored SIGHUP, whereas firefox,
> gimp, abiword, konqueror and others all terminated.
>
Thanks for this more extensive survey, comments below.
>> And user expectation that an
>> interactive session (which may e.g. contain an editing session with unsaved
>> changes...) should not be aborted by an unrelated event.
>>
> You do have a point there (which is why mintty has the warning when
> it's closed with background processes running). Closing the terminal
> that a program was started from is not a completely unrelated event,
> though, and there might well be users that do expect everything to
> quit in that case. In other words, you don't help your case by stating
> opinion as fact and ignoring the other side of an argument.
>
Well, I didn't mean "should" as stating a fact but more as a request for
discussion (contributors welcome).
(Maybe one *should* be aware that the usage of "SHOULD" in RFCs may have
somewhat tweaked the perception of "should" in computing language,
or I might have added an IMHO attribute :-) )
Concerning
> Closing the terminal that a program was started from is not a completely unrelated event,
this is also a matter of taste and use case but just using a command
line to *start* an application does not indicate the intent that the
command line should continue to *host* the application in the sense of a
session.
My case is that sturdiness of an application against external impact is
the more desirable the more interactive and potentially unsaved data it
maintains.
This is not so much the case with browsers but at least firefox has
introduced the feature of "Restore session" as a remedy in case it gets
killed.
It is more the case for a shell session and even more for an editor.
Your survey above may also be interpreted this way: the most established
terminals (xterm, rxvt-unicode) do maintain this stability, while some
"newcomers" don't care (yet).
Among editors, apparently gvim supports my point, while emacs, gimp,
abiword don't - but that can also just mean the issue has not received
common awareness by now.
>> 2. Manual termination of a terminal with a window manager operation (like
>> clicking the Close X button, selecting Close from the menu, pressing
>> Alt-F4).
>> In the case of a Windows application, this is a WM_CLOSE message being
>> handled (not a HUP as I had assumed).
>> If the direct child process of the terminal explicitly catches HUP, the
>> terminal should not terminate. It should just send HUP to its child and then
>> terminate only if the child terminates (overriding a "hold after command
>> terminates" option in this case, so the option can be reset when handling
>> this).
>>
> Here we go again.
>
> My little survey showed that xterm is the only terminal that does
> things that way; all the others notify the child and quit immediately.
>
Maybe that's why xterm is still the mainstream terminal in the X world?
(+ IMHO + ;-) )
>> It also works with mintty but only once, due to the 'killed' flag in the
>> function child_kill in child.c
>>
> Funnily enough, this was a deliberate design decision, i.e., a
> compromise between the two approaches. Unlike rxvt et al., it does
> allow an application to say bye and prompt about unsaved data. Yet
> unlike with xterm, a misbehaving application won't stop the user from
> closing the terminal, because guess who'd be blamed for that.
>
A well-considered approach; however, since mintty is the only terminal
that applies this compromise, applications cannot assume this as a
protocol, so I doubt there is much use case.
Actually I noticed xterm also implements a useful compromise: With a
window manager close event (Click "X", Alt-F4) it behaves as I had
described, with "Quit" from its own menu, on the other hand, it always
quits, thus avoiding the problem of an "unkillable" terminal.
Finally, let me discuss again my use case of embedding an application
into a terminal ("container" model): the "HUP-delegate" protocol that I
favour would enable a text-based command-line application to raise
itself to a desktop application, including the option of implementing
any application-specific "Really exit?" or "Save first?" behaviour. This
would be another great feature of the terminal.
So please consider again these two options:
* Follow xterm like this: Apply "HUP-delegate" (i.e. forward HUP, leave
quit decision to application) to the top-right Close button ("X"), and
quit on Close from the menu; (Alt-F4 is not a big issue since it's
remappable already.)
* Offer an option to apply "HUP-delegate" to "Close".
------
Thomas
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -