Bugzilla – Full Text Bug Listing
| Summary: | [terminal][local] Unexpected dialog on quit-workbench about unterminated terminal sessions | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] Target Management | Reporter: | Martin Oberhuber <mober.at+eclipse> | ||||||||||
| Component: | Terminal | Assignee: | Martin Oberhuber <mober.at+eclipse> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Martin Oberhuber <mober.at+eclipse> | ||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | eclipse | ||||||||||
| Version: | 3.2 | ||||||||||||
| Target Milestone: | 3.2 RC3 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 169761 [details]
Patch to disable the unexpected dialog (unless explicitly configured by the user)
The confirmation dialog helps prevent loss of data for users who are in the habit of launching additional child processes from a shell. Personally, I frequently start other editors or tools from a shell and have often lost unsaved work when I closed a shell that served as parent to a whole bunch of other processes.
I understand that this depends on how a user typically uses a shell and may be perceived as annoying by users who frequently restart their workbench and usually don't start other processes from a shell.
To address the issue, I added a very simple preference page as a child of the Terminal preference page that allows the confirmation dialog to be turned on. By default it is switched off and no dialog will appear during workbench shutdown.
I'm not a fan of too many preference pages, especially not a month after UI freeze.
> habit of launching additional child processes from a shell. Personally, I
> frequently start other editors or tools from a shell and have often lost
> unsaved work when I closed a shell that served as parent to a whole bunch of
> other processes.
Starting an editor from the Eclipse local terminal begs the question why you don't use an Eclipse Editor for this?
I do see the point that there _might_ be unsaved data in your terminals. But turning the question around: assuming that Eclipse never asks about your still-open terminals, would you perceive this as a limitation or would you adjust to this fact? I haven't seen Emacs ever ask about an open Shell on quit, and the Telnet, SSH and Serial connectors also do not ask. Nor does the RSE Shell Subsystem (I'm not sure about the Sourcefoge WickedShell plugin). So why do something special for local?
One of the benefits of having local terminals integrated in Eclipse (as opposed to a terminal window on the desktop) is that the terminals associated with some context of work (e.g. a Workspace) can get closed and re-opened as I close / re-open that context. Asking back to some extent voids this advantage.
If you do feel a strong need for making this feature configurable, is there a way doing so without a Preference page? For instance, the "Create New Terminal" Dialog could have an associated checkbox; and the "Terminals still open" dialog on exit could have a "Do not Show Again" checkbox to set up the opposite. That way, a user could make the setting at a place where it's obvious, without having to switch context into the Preference pages.
But if it were me, I'd prefer not having the option at all.
I'm considering committing the patch but without the Preference Page UI. That way, I get the default behavior that I want. While a product builder can set the non-UI preference in plugin_customization.ini if desired. And in the future, we can think about adding end-user accessible UI for that Preference. Does this sound acceptable? (In reply to comment #2) > Starting an editor from the Eclipse local terminal begs the question why you > don't use an Eclipse Editor for this? We have lots of domain-specific languages and binary formats at my company and unfortunately very few of the associated editing tools are running in Eclipse (though I'm always working on fixing that). > I do see the point that there _might_ be unsaved data in your terminals. But > turning the question around: assuming that Eclipse never asks about your > still-open terminals, would you perceive this as a limitation or would you > adjust to this fact? It really depends on your mode of working. I personally have often lost data by killing a shell and inadvertently killing a bunch of other tools that were started from that shell, and I know a lot of people who have run into the same problem. I also know a lot of people who never have experienced this kind of issue, which is why I think it should at least be an easily configurable option. (In reply to comment #3) > I'm considering committing the patch but without the Preference Page UI. That > way, I get the default behavior that I want. While a product builder can set > the non-UI preference in plugin_customization.ini if desired. And in the > future, we can think about adding end-user accessible UI for that Preference. > > Does this sound acceptable? Sure. I don't really see a hard reason to exclude the preference page, but the final decision is up to you. (In reply to comment #4) > I don't really see a hard reason to exclude the preference page, but the > final decision is up to you. Random collection of thoughts: 1/ A prefspage with just 1 setting is ugly 2/ The Terminal prefspage itself is mis-placed on toplevel 3/ Once the prefspage is in, it's hard to remove again (similar to API) 4/ Have to make the setting outside context of what I'm setting 5/ Eclipse has too many prefspages already 6/ Prefspage UI should have associated userdocs, thus creates more work 7/ Prefspage is visible to EVERYONE who has the feature installed, regardless of whether interested in the feature or not (could be adressed by Capabilities on product level, but this doesn't scale well) Issues 5/ and 7/ make me dislike prefspages in general; in this particular case, 4/ and especially 3/ are the strongest arguments. Adding UI is like adding API, and this should never be done without enough time to reiterate on the decision. Which we don't have that close to the release. You're right, we don't have the time to thoroughly think this through, and once it's in it's hard to take it out. I'm fine with committing it without the preference page. We can revisit the issue later when we have more time. Actually, what about adding the UI setting to your Local Terminal Launch Configuration tab, e.g. "Ask confirmation before closing this session on quit". That way, those of your local terminal launch configs that are associated with your special DSL editors etc could have an "ask on quit" setting, whereas default terminal launches would not. I'm not entirely sure whether the granularity of this setting should be a global Preference or configurable per-Launch. Perhaps something to think about rather than rush in too hurried. (In reply to comment #7) > Actually, what about adding the UI setting to your Local Terminal Launch > Configuration tab, e.g. "Ask confirmation before closing this session on quit". Yes, that's a good idea. > Perhaps something to think about > rather than rush in too hurried. I think of this more as a global option, which would make it feel somewhat misplaced in the terminal settings, which are per connection. Let's postpone this for now, I'm sure we can come up with a good solution later. I cannot get rid of the UI from the patch easily, since the Preference constant is embedded in the Preference page UI code (yuck!). Please refactor the Preference constant into non-UI, update the Copyright Year of LocalTerminalStillRunningListener, and re-attach. I assume that only LocalTerminalStillRunningListener and perhaps the Activator need changing. And by the way, could the text of the warning message be simplified? (In reply to comment #9) > I cannot get rid of the UI from the patch easily, since the Preference constant > is embedded in the Preference page UI code (yuck!). Oops, sorry. I'm getting sloppy here. I'll refactor that as requested. Created attachment 170136 [details]
Patch to disable the unexpected dialog
The preference constant is now in LocalTerminalActivator. I also shortened the message from the original confirmation dialog.
Created attachment 170159 [details] updated patch I made a few minor modifications to the patch: 1.) Made prefs constant uppercase, i.e. CONFIRM_TERMINATE since this is the standard for most prefs constant in plugin_customization.ini as well as for RSE, see http://dsdp.eclipse.org/help/latest/topic/org.eclipse.rse.doc.isv/reference/misc/runtime-options.html 2.) Added more Javadocs for the prefs constant in order to ensure that in the future we understand this is a sort of API, i.e. the value of the constant cannot be changed without breaking users who use this in plugin_customization.ini 3.) Changed the dialog text to active form, i.e. "Workbench is about to shut down" because that is easier to read and undstand than "...to be shut down..." 4.) Changed text of the confirmation button to "Quit Anyways" since I believe the trailing s was missing as a typo. When testing, I noticed that even though confirmation is off, Workbench is very slow quitting when multiple local terminals are open. I filed bug 314632 for this, and I believe that's an important issue to look at. Released >= I20100527. |
Created attachment 169258 [details] Screenshot of dialog on exit Can we avoid the dialog on exit (attached)? Any tool that I'm aware of just terminates its child processes without asking on exit. As the local terminal becomes more generally used, I expect to always have a local shell open -- I wouldn't want to always accept this dialog on exit.