GNOME Bugzilla – Bug 168320
Make a guess about active foreground & background processes for close confirmation
Last modified: 2021-06-10 16:07:26 UTC
It would be nice, if feasible, for gnome-terminal to take a look at its child processes when closing a window to see if anything is running except the shell (check against /etc/shells or similar), and use this information to decide whether or not to pop up a close confirmation dialog. This would put a stop to silly mistakes for users who occasionally launch X apps from terminals and then forget and close them.
Created attachment 120586 [details] [review] proof-of-concept Only checks foreground processes though.
*** Bug 560775 has been marked as a duplicate of this bug. ***
Committed an updated patch. Still only working for foreground processes; leaving the bug open for more work if we can find out how to get info on background processes.
Christian, this feature is very useful for me, but some people don't like it (Bug 567941). Also, from my bad experiences, sometimes a prompt for close confirmation is necessary even when no process is running inside the terminal. By example, the outputted results in the report done on Bug 485802 could be printed by a finished process. I saw you added a bool "confirm_window_close" that can be changed by using Gconf Editor. So, I suggest change it to an enum like "confirm_terminal_close" and add to Profile Preferences dialog another ComboBox below "When command exits". Example: When command exits: "Exit the terminal" "Restart the command" "Hold the terminal open" ("Hold the terminal open on error"? -> if included by Bug 491807) Prompt when closing terminal: "Always" "Never" "When a (foreground?) process is running" (-> default) These two ComboBox shall not conflict. "Prompt when closing terminal" will be hit only by an user action (on click "X" to close a tab or window, or select the option via main or pop-up menu). PS: Bug 461870 is also related to this topic.
*** Bug 461870 has been marked as a duplicate of this bug. ***
*** Bug 485802 has been marked as a duplicate of this bug. ***
Created attachment 128242 [details] [review] Adds a "Prompt when closing terminal" profile preference This patch, for Gnome-terminal 2.25.3, implements what comment 4 suggested, so people with same opinion can tried it.
I don't think this should be a profile option. If anything, it should be a global option.
Ok, may be a global option. I must admit, I just use the default profile. :-) If yes, the more appropriate place I see to include the option, without considering a new dialog just for global settings, would be above "Close Tab" and "Close Window", at "File" menu. An entry which leads to a submenu with radio options.
*** Bug 568538 has been marked as a duplicate of this bug. ***
*** Bug 553009 has been marked as a duplicate of this bug. ***
Created attachment 131095 [details] [review] Adds a "Terminal/Confirm on Close" submenu This patch, for Gnome-terminal 2.26.0, adds a "Confirm on Close" submenu, to make possible to configure how the confirmation to close the current terminal or window will behave when the action is triggered through the GUI. My previous patch also added this configuration, but each terminal could had a different setting and only the setting of the current terminal was verified when closing (wrongly). Now, with this new patch, it is a global option, like pointed by Christian Persch at comment 8. The submenu is added to the Terminal menu, not a good place I think because it had only options and actions that applies to the current terminal, and the new option is global.
Does it really make sense to have this a per-terminal thing? Do you really expect users to bother to set this preference with that granularity? Having this in a profile makes more sense (so users can set up a profile which they use to get prompts, and another which does not). But... If the algorithm to guess whether to ask or not is good at all, then IMO this should be a hidden preference, much as confirm_window_close, which sufficiently annoyed users can toggle using gconf-tool or a gtweakui-type app, and which defaults to active. If the algorithm is not that good, then I really wonder if it should not get better before doing this ;-)
Created attachment 131226 [details] [review] New try, put the close configuration submenu on Edit menu. > Does it really make sense to have this a per-terminal thing? Do you really > expect users to bother to set this preference with that granularity? Well, I said the Terminal menu was not a good place... I was tired when wrote the last comment, then it became incomplete/confuse. The patch added a submenu with radio options to set a global configuration of the confirmation on close. The Terminal menu wasn't a good place because all other options are per terminal, and the confirmation on close configuration is global. I'm attaching here a new patch which instead adds the submenu on Edit menu, maybe too generic but I hope will not cause confusion. > Having this in a profile makes more sense (so users can set up a profile which > they use to get prompts, and another which does not). But... My first patch follows your suggestion, but fails on verification of what is set for each terminal, because they can be created with different profiles. If we agree the profile option makes more sense, maybe I can fix the verification on exit of that patch. What I can say now about gnome-terminal is that in its all profiles-oriented setup, a global setting does not fits well. > If the algorithm to guess whether to ask or not is good at all, then > IMO this should be a hidden preference, much as confirm_window_close, > which sufficiently annoyed users can toggle using gconf-tool or a > gtweakui-type app, and which defaults to active. If the algorithm > is not that good, then I really wonder if it should not get better > before doing this ;-) Well, I feel Gnome users are not used to gconf-only options. When a gnome application does not provide an option on it's GUI or command line, I assume it doesn't support that option. Maybe it's because a Gnome application in general has few options and some empty space is free on the GUI. For me it's a different case of the "about:config" options of Firefox, what may seem strange. "about:config" is one of the first places I look if an option isn't found. The current confirm_window_close gconf option does not provide a way to always confirm on close, what some users would want (myself included, I'm serious). I have "fixed" my problem a long time by hard-coding a solution, but I prefer to offer a more elegant way because probably someone else will want the same. At least now a patch is available, so anyone able can apply. We may continue cooking a solution and apply it if it becomes ready.
Reviewing attachment 131226 [details] [review]: The setting should be a property on TerminalApp, and the code to load it from gconf also live there instead of in TerminalWindow. I'm not sure I'd add visible UI for the setting; at least separate that part of the patch out into another patch. For the setting's enum, should use a typedef and GType so it can be used in a GParamSpecEnum; TerminalProfile has code for gconf-to-enum that can be copied (or refactored to terminal-utils?).
I have a suggestion as to where to put the UI bit of this preference. How about the first time one closes a terminal window, a window comes up asking whether you would like confirmation to be requested in the future? So the first time I run gnome-terminal, and close a tab/window, a dialog pops up and says "Please confirm that you wish to close this terminal" with OK and Cancel. But below that would be some radio buttons to indicate how this request would be handled in the future. Perhaps [] always ask confirmation [default] [] request confirmation if it appears a process is running [] request confirmation only if it was not the primary tab [] never request confirmation. Just an idea.
*** Bug 732120 has been marked as a duplicate of this bug. ***
*** Bug 461865 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/3057.