Community
Participate
Working Groups
Just entering this to hold the thought for discussion later... I noticed the pattern with the Find Type command (cmd-shift-T), but it probably happens elsewhere: As soon as I hit the accelerator, I expect to be able to start typing the name of the class. What happens now is that a progress dialog opens, and then the list of programs. Any keys typed before the file list is opened are ignored. It would be cool if applications could say "collect any keys that are pressed" in the progress dialog so that the application code code then pass them on to the next dialog when it opens. Obviously there are interesting implications, but the alternative is to force them to write their own progress dialog (or is it?).
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.
