Summary: | [KeyBindings] [Progress] Progress dialogs should capture keys | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Mike Wilson <Mike_Wilson> |
Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
Status: | ASSIGNED --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P5 | CC: | andre_weinand, bokowski, douglas.pollock, john.arthorne, thomasw, Tod_Creasey |
Version: | 3.0 | Keywords: | helpwanted |
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Mike Wilson
2003-11-28 09:53:20 EST
In general there is currently no support for keybindings in dialogs - so I am not sure if this is possible. Doug might have some insights so I'll add him to the cc list. This is not a problem of not having key bindings in dialogs. What Mike is talking about is something else. Key bindings would be the ability to use his Emacs cut&paste keys (for example) in the text field. What Mike is talking about is having a generic system of key buffers. I was already thinking of providing key buffers for blocking operations (i.e., if the key filter is disabled, it merely queues operations waiting until they can be run). However, this sounds like he would like all key presses (not just bindings) to be buffered intelligently. I'm going to take ownership of this bug for consideration with key bindings in dialogs work. Rough draft: dialog = <create progress dialog> KeyBuffer buffer = WorkbenchKeyboard.createKeyBufferOn(dialog) <open dialog, run event loop, generally mess about, then close dialog> dialog = <create modal open type dialog> buffer.dispatchEventsTo(dialog); This might require work from SWT.... *** Bug 46719 has been marked as a duplicate of this bug. *** From Bug 46719: "Pressing Ctrl-S, Ctrl-Shift-S, F11 in fairly rapid succession and various order often seems to ignore the 'save all' or 'launch' if Eclipse was busy compiling/ launching/ terminating." I think this is probably something to do defer until post-3.0. Thoughts? The intent of my original comment was to spark some discussion about a responsiveness issue that we had not addressed, *not* to generate a new work item. Defering is fine, as long as it doesn't get closed. Moving Dougs bugs There are currently no plans to work on this feature. PW Note, for us to have a truly responsive search based navigation story, we will need functionality like I described in my original comment. For those interested, bug 144469 is open for solving this problem in the open type dialog in particular. It's not clear that generic support from the workbench is needed to make this happen. They should be able to open the dialog immediately, and then fill in the type list in the background, as is done in the Open Resource dialog. responsive search This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. |