Comment 1 Douglas Pollock 2004-11-19 15:42:48 EST

Tod: are you attaching a key listener to the progress view? 
 
On Linux GTK+, ESC never closes the progress view.  On Windows XP (Kim's 
machine), she sees the behaviour you describe. 

Comment 2 Tod Creasey 2004-11-19 16:02:10 EST

Released to R3_0_maintenance

Comment 3 Tod Creasey 2004-11-19 16:02:45 EST

Ignore the last comment. Wrong report

Comment 4 DJ Houghton 2004-11-19 16:03:58 EST

Should we re-open this then? ;-)

Comment 5 Douglas Pollock 2004-11-19 16:07:15 EST

blah 

Comment 6 Tod Creasey 2004-11-19 16:12:35 EST

I don't add any listeners to the JobsView

Comment 7 Douglas Pollock 2004-11-19 16:31:38 EST

I take it back.  This happens on GTK+ as well.  The key is that the progress 
view must be empty for ESC to work.  If there are items in the progress view, 
then it does not work. 

Comment 8 Douglas Pollock 2004-11-22 08:43:45 EST

In talking with Stefan, it seems that it is not supposed to be possible to 
close detached views with ESC ever.  This is a bug in how the shells are 
created for detached views. 
 

Comment 9 Stefan Xenos 2005-07-20 12:52:36 EDT

Closing detached views with ESC has been in long enough now that it is now
supported behavior.

Comment 10 Mirko J. Ploch 2005-09-02 10:35:55 EDT

(E3.2M1)
Why is escape used to close a detached view? I find this anoying. It makes sense
for dialogs when you are trying to abort an operation, but not the detached
view's window. Besides ALT-F4 can be used to close the detached view window. I
have a dual monitor setup and like to keep an external window open in the second
monitor that contains multiple views. Sometimes when I perform an operation form
the external window that I decide to abort by hitting escape, I accidentially
hit escape multiple times and lose my external window with all the views that I
had setup. :-( At least please provide a way to disable the escape key so it
does not close the detached view window. I tried to find something in
Window>Preferences...>General>Keys to disable the escape key, but I didn't see
anything.

Just my 2cents

thx,
-=mirko=-

Comment 11 Joshua Salit 2005-10-20 17:43:32 EDT

Allowing ESC to close the detached view is very unpleasant for me - In my RCP
app, I have a ViewPart that implements ISaveablePart2, and returning CANCEL from
promptToSaveOnClose() doesn't stop the close from happening.  The View is not
closed directly, but the DetachedWindow's PartStack is still disposed, so the
View loses it's site anyway.

It would be a big help if this was at least made optional behavior.

Comment 12 Douglas Pollock 2005-10-21 09:07:46 EDT

I'd like to try once more to get this patch applied to the DetachedView code.  
Feel free to disagree or ignore me.  This removes the parent shell from 
detached views.  On all platforms, this makes it so that: (a) ESC cannot close 
the detached view; and (b) detached views do not obscure the main eclipse 
window.  See also Bug 56498 and Bug 96428. 
 
The side effect is that all of the windows will appear in the task bar on 
Linux (not sure about other platforms).  However, this is somewhat expect on 
Linux, as this is how The GIMP works. 
 
Index: Eclipse UI/org/eclipse/ui/internal/WorkbenchWindow.java 
=================================================================== 
RCS file: /cvsroot/eclipse/org.eclipse.ui.workbench/Eclipse 
UI/org/eclipse/ui/internal/WorkbenchWindow.java,v 
retrieving revision 1.298 
diff -u -r1.298 WorkbenchWindow.java 
--- Eclipse UI/org/eclipse/ui/internal/WorkbenchWindow.java	7 Oct 2005 
13:30:46 -0000	1.298 
+++ Eclipse UI/org/eclipse/ui/internal/WorkbenchWindow.java	21 Oct 2005 
13:00:18 -0000 
@@ -842,7 +842,7 @@ 
     protected void configureShell(Shell shell) { 
         super.configureShell(shell); 
  
-        detachedWindowShells = new ShellPool(shell, SWT.TOOL | SWT.TITLE | 
SWT.MAX | SWT.RESIZE | getDefaultOrientation()); 
+        detachedWindowShells = new ShellPool(null, SWT.TOOL | SWT.TITLE | 
SWT.MAX | SWT.RESIZE | getDefaultOrientation()); 
          
         String title = getWindowConfigurer().basicGetTitle(); 
         if (title != null) { 
 

Comment 13 David Henderson 2008-07-21 17:47:31 EDT

I fully agree with #10 and #11.  I just discovered the behavior myself in my RCP app (while trying to prevent Esc from closing dialogs that I use in my RCP) and it is indeed very annoying.  So is there an easy way to disable this behavior as of 3.4?

(In reply to comment #11)
> Allowing ESC to close the detached view is very unpleasant for me - In my RCP
> app, I have a ViewPart that implements ISaveablePart2, and returning CANCEL from
> promptToSaveOnClose() doesn't stop the close from happening.  The View is not
> closed directly, but the DetachedWindow's PartStack is still disposed, so the
> View loses it's site anyway.
> 
> It would be a big help if this was at least made optional behavior.

Comment 14 Eric Moffatt 2008-07-22 11:59:03 EDT

Just to note that the effect describe3d in comment #11 has been fixed in 3.4. Savable views now prompt on close (see bug 232556).

I'm going to remove the ESC handling from DW's...it's life-cycle is -not- intended to be short, logically it's part of your workbench window (which you can't close using ESC) and the pain to restore it on an accidental close is severe.

In order to support accessibility we'll have to provide a system menu with at least close on it to allow the close to be accessed via the keyboard.

Comment 15 Eric Moffatt 2009-03-05 15:47:24 EST

Moving to triage...note that this is not being marked as an enhancement because adding the 'close' menu is necessary for accessibility...

Comment 16 Boris Bokowski 2009-05-15 13:11:04 EDT

(In reply to comment #14)
> I'm going to remove the ESC handling from DW's...it's life-cycle is -not-
> intended to be short, logically it's part of your workbench window (which you
> can't close using ESC) and the pain to restore it on an accidental close is
> severe.

+1 for not closing detached views when you hit ESC. Can we target this for 3.6?

Comment 17 Eric Moffatt 2009-05-15 13:43:25 EDT

For sure, the main thing that was holding it up was that it'll require a fair bit of work to manage the accessibility issues...

Comment 18 Eric Moffatt 2009-11-24 09:46:53 EST

...which we don't have time for in 3.6. I'm going to transfer this to the 4.0 target to (hopefully) make sure that we don't paint ourselves into the corner there as well.

Comment 19 Remy Suen 2011-10-10 20:54:45 EDT

(In reply to comment #18)
> I'm going to transfer this to the 4.0
> target to (hopefully) make sure that we don't paint ourselves into the corner
> there as well.

Looks like they still close when you hit the ESC key as of I20110923-1625.

Comment 20 Eric Moffatt 2011-10-12 13:20:17 EDT

How odd...I'd removed the red 'x' thinking (incorrectly as it turns out) that this would also remove the ESC behavior.

I'll check with SWT to see if there is a style I can use that prevents this from happening...

Comment 21 Viatcheslav Sysoltsev 2012-01-11 07:22:45 EST

Not sure if I understand the problem, but for restricting ESC to close the shell, you may register listener on SWT.Traverse and command to ignore event, like this:
.addListener(SWT.Traverse, new Listener()
{
    @Override
    public void handleEvent(Event e)
    {
        if (e.detail == SWT.TRAVERSE_ESCAPE) {
            e.doit = false;
        }
    }
});
Sorry once more if I suggested something trivial and the problem is more subtle

Comment 22 Eric Moffatt 2012-06-01 15:52:24 EDT

Another one bites the dust using 4.2...;-).

*** This bug has been marked as a duplicate of bug 151510 ***