Community
Participate
Working Groups
Generally any window can be closed using command-W. Our dialogs don't conform to this behaviour... not sure if they should.
Paul, do you think this is something we should do?
Fixing up the binding for mac would just be nulling out the help M1+W in dialogs (Help - Close Tray) and pointing to a close dialog command. Implementing a close dialog command that works across our dialogs seems to be complicated, however. Susan, do you have an idea of how to do that? PW
There is public API to close a window, but the trick is setting the correct window return code. A CANCEL return code is typically what is set when the user closes the shell by clicking on the close box. This would require a public way to set the return code of the window before calling close(). I guess the bigger question is whether this is an important enough issue from a Mac user's perspective. When Kim first opened the bug, the comment was "not sure" if we should conform to this behavior, so I don't know if there's any question as to whether this should be done. cc'ing Andre since he is also a mac user.
Yes, being able to close all windows with Command-W is important. And I don't understand the technical problem since Command-W should do exactly the same as clicking on the windows close button. So could not the handler for Command-W just call the handler that is installed for the window's close button? How is this done on Windows? IIRC some function key (F3?) is equivalent to pressing the windows close button.
I can look at this during M2. In the meantime, cc'ing Steve...should command-W "just work" on the Mac from an SWT point of view?
I'll just mention that COMMAND+W in a workbench window doesn't close the window, it just closes the active editor. PW
Removing milestone. We simply ran out of time.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
*** Bug 117577 has been marked as a duplicate of this bug. ***
I miss this all the time. For modal dialogs without a close box (e.g. Open File), it's OK to just support Esc for Close, but if the red close button is active in the title bar, then Command+W should work.
Created attachment 149908 [details] Patch v01 (1) We need to remove the Cmd+W keybinding for Close Tray in the help. (2) As Susan mentioned in comment#5, we need a public way to set the return value in the Dialog. (I've made the Window.setReturnCode() public in my workspace for this patch to work, but that would break binary compatibility) Susan, adding an API in Dialog is possible?
Updating the dependency with the right bug id :-)
Remy suggested using reflection to avoid introducing a public method. Given the nature of the use case and the fact that handlers already use reflection extensively (see WidgetMethodHandler), I wonder if this is a better choice.
I don't think you need bug 293025. Why don't you just call Shell#close()? That should do exactly what the user gets when she clicks the close button. If the dialog wants to veto the closing, then it should be able to do so. And I think the keybinding should only be active for platform="carbon".
Created attachment 151671 [details] Patch v02 (In reply to comment #14) > Why don't you just call Shell#close()? Its because that doesn't set the return code to CANCEL and doesn't do the cleanup in Window/Dialog. hmmm but wait. It looks like Window.handleShellCloseEvent() just does that. So Shell.close() should be fine. Thanks Markus. > And I think the keybinding should only be active for platform="carbon". Why do we need this? The fix is on the cocoa fragment. (a similar patch for carbon fragment is needed)
> > And I think the keybinding should only be active for platform="carbon". > > Why do we need this? The fix is on the cocoa fragment. (a similar patch for > carbon fragment is needed) Oh, I missed that the fix is in the fragment, so it's maybe really not needed (assuming that extension points are really not read when a fragment is not loaded).
Created attachment 153417 [details] Patch v03 Patch for both carbon and cocoa fragments
Patch v03 released to HEAD
I don't believe you can just define a keybinding for "M1+W", since I see a binding for Close Tray in dialogs for that sequence. You need to define a cocoa or carbon binding for M1+W in your fragments. PW
(In reply to comment #19) > I don't believe you can just define a keybinding for "M1+W", since I see a > binding for Close Tray in dialogs for that sequence. You need to define a > cocoa or carbon binding for M1+W in your fragments. > > PW The bug # 294571 is opened for the Close Tray already. I've defined the bindings in the respective fragments only. Didn't understand what should be done.
(In reply to comment #20) > > The bug # 294571 is opened for the Close Tray already. > > I've defined the bindings in the respective fragments only. Didn't understand > what should be done. If I provide a plugin and include a keybinding in dialogs to M1+W, as soon as you launch on carbon you will get an error, and M1+W will do nothing. We protect ourselves against this by targetting our keybinding on carbon (since it is carbon specific) which means it will be chosen over a non-platform specific keybinding for M1+W PW
Created attachment 153493 [details] Patch v04 (In reply to comment #21) > We protect ourselves against this by targetting our keybinding on carbon (since > it is carbon specific) which means it will be chosen over a non-platform > specific keybinding for M1+W > > PW Ok. This would do?
(In reply to comment #22) > Ok. This would do? I think that's all it needs. That will give those bindings priority on carbon and cocoa respectively. PW
Patch v04 released to HEAD
Verified in I20091207-1300
