Community
Participate
Working Groups
The New Class dialog does not support CTRL-A in entry fields. You can right- click and choose "Select All". This slows down keyboard-based usage of eclipse. This odd discrepency shows up in many places in eclipse. It would be great for all of eclipse to have these annoying UI nits cleaned up in one pass. Thank you for considering this request. Version: 2.1 Build id: 200302061700
We entered code freeze for 2.1, so only critical bugs will be addressed. Have to postpone > 2.1 since as you mentioned this is the case for every text input field.
Ok, thanks, as long as it is on the to do list for a post 2.1 "I" build, I am happy. BTW, will the fix work for all entry fields? All UI widgets where selection is allowed (list boxes, etc) or is this a dialog by dialog, window by window issue? It seems that logging an issue per dialog would be a waste of bugzilla resources. Thanks.
That has to be discussed with SWT. May be the can do it for all entry fields.
Reopening...
Nick, what do you think about consistent Ctrl+A. Would it be possible to add support to JFace/SWT so that we only have to provide extra code in "unusual" situations.
These are just plain text fields, which do not need to specially handle the Edit / Select All global action since they are in dialogs, not the main eclipse window. All the other actions on the context menu have shortcut keys, but not Select All. Moving to SWT for comment. Is this an OS limitation? Is it something that SWT can provide?
The fact that there is no Ctrl+A build into the text field is an operating system limitation. It might be possible to hack our text widget to look for the key sequence but this would not get the cases where text widget appear in native dialogs (FileDialog), in combo boxes and in OLE controls. It is also not the SWT policy to "improve" the operating system.
Moving back to UI.
*** Bug 41237 has been marked as a duplicate of this bug. ***
From Bug 41237: "The shortcut keys for cut/copy/paste are different for editor views and dialogs. In an editor view the keys are Ctrl-x, Ctrl-c and Ctrl-p. In a dialog the keys are the Cut, Copy and Paste keys on the Sun keyboard (the extra keys on the left side of the keyboard). This leads to unintuitive behaviour because if I wan't to copy something from a properties dialog to an editor view, I have to copy it with the Copy key and paste it with Ctrl-v." For this bug to be fixed, dialogs must support key bindings.
understood. assigning to you to make key bindings work in dialogs as per our previous discussion. (replacing entire command->action map in the command manager when the dialog is open. the guts of this code should be put in workbench - possibly in updateActiveCommandsAndContexts - and not in command manager)
*** Bug 29436 has been marked as a duplicate of this bug. ***
Also, "Previous Line" and "Next Line" (pop-up windows, code assist, outline browser). Other note about Emacs key bindings.
Adding Kevin as CC, since the debugger needs this to allow key-bindings to be used in new evaluation popups.
Fixed in CVS. By default, key binding definitions with no context id specified will be bound to work in windows. It is possible to define key bindings to work in: windows, dialog, or dialogs and windows. This is done by associating the key binding with the correct context (see the contexts defined in "plugin.xml" for "org.eclipse.ui"). These contexts are given special meaning by our implementation of IWorkbenchContextSupport. This special meaning is as follows: if a context inherits from the dialog context, then it can only be active if the dialog context is active. Similarly, for the "windows" and "windows and dialogs" contexts. These allows context developers to restrict their contexts to particular types of windows. In the keys preference page, these three contexts appear in the "When" combo box and in the tables. I have provided four global handlers as an example of how to write generic handlers for dialogs. These handlers provide cut, copy, paste and select all in dialogs and windows. (See WidgetMethodHandler in "org.eclipse.ui.workbench"). I have opened a Bug 55394 against Platform Text to provide the two currently unsupported functions mentioned here: next line and previous line.
Does this mean that as a user of the next M build I'll get cut/copy/paste/selectAll for free in a dialogs or does each dialog must be coded to support these default bindings? Thank you.
Right, I forgot to mention this. This is how shells are classified by the workbench.... By default, any shell with a parent is considered to be a dialog. If the application developer does nothing, then a parented shell will be treated as a dialog. This means it will receives key bindings bound to "dialogs and windows" or "dialogs" (or child contexts of those two). [My test case was to get the four handlers I mentioned working in the Find/Replace dialog, for example.] By default, any shell without a parent is *NOT* considered to be a window, nor is it considered to be a dialog. Since all key bindings are now rooted to "windows" by default, this means that the vast majority of key bindings will not work in this shell. (I am aware of a couple conditions where debugging key bindings might be processed currently; hopefully, these will be fixed quickly.) However, there is a registration process by which a shell can tell the workbench what type of shell it is. Using this system, a shell can say it is a dialog (i.e., key bindings that have declared themselves to work in dialogs), a window (i.e., most key bindings) or neither (i.e., don't provide any of them).
Is it necessary to introduce the extra complexity of dialog and window+dialog contexts to the user? As far as the user is concerned, if they bound a key to a command (in the global scope), then that key should work in dialogs as well. I think our key bindings dialog is confusing enough without introducing some new dimension of contexts. I also think it will complicate life for developers. For example, if we were to register a hanlder for the Collapse All command in all dialogs/wizards/pref pages where it makes sense, I wouldn't expect to have to associate Collapse All with some new context(s). And whose responsibility would it be to make this association, the plugin defining the command, or each handler? What problem is being addressed by the new contexts? When in a dialog, I'd expect the keybindings for any commands that are relevant in that dialog to automatically apply. Usually the set of commands typically applicable in a dialog is pretty small (e.g. cut/copy/paste/select all). I wouldn't expect it to inherit bindings for commands in the parent window, but I think this could be done by just knowing which commands are relevant in the dialog, without resorting to extra contexts.
I second Nick's concerns. The keybindings story is already complex enough without adding another context.
i also expressed strong disagreement with using contexts to solve this problem. i feel a solution can be reached (in 3.0 :) without this complexity.
The majority of keys bound in the old "global" context do not apply in dialogs -- and should not apply in dialogs. There is a limited subset of key bindings that should apply in dialogs. The current mechanism for controlling key bindings is contexts. While I agree that keys preference page is complex as it is, I feel that an explosion of contexts is already going to happen -- simply consider the case of what we'd expect people like Websphere to build on top of such a mechanism. This is something that should be dealt with at the level of the preference page itself, rather than by being afraid to use contexts. I agree that there is some weirdness to the distinction between the key binding and the command itself. To answer Nick's question, I believe that the developer defining the command would also define the key binding. By the time the handler developer comes along, the decision has already really been made as to whether the command should apply in dialogs. To me, this seems to follow the ontology we are using: commands are meant to represent the semantic definition of an action. The "find/replace" command, for example, does not work in dialogs as it implies opening a dialog. That being said, there is nothing to prevent the handler developer from "promoting" the key binding to work in dialogs and providing their own dialog handler. But again, dialog commands are definitely an exception rather than a rule. Part of the reason for this distinction goes back to a conversation with Mike Wilson. He conjectured situations in which Emacs-style key bindings (for example) would apply only in text editors, and not elsewhere (e.g., dialogs). The system I've implemented provides flexibility for the developer (and the user) to make this decision.
I could be wrong but I'm not sure this is a good idea. For one thing, it seems like a lot of trouble just to get Ctrl-A to work in text fields as per the original request. Also as a user I would not really expect any key bindings that I have set up in the preferences window to be active in dialogs. Maybe my expectations are too low :) but the only keys I expect to work in dialogs, especially text fields in modal dialogs, are the regular typing keys, labeled keys like Home and End, and native accelerators like Ctrl-C, Ctrl-V, and Ctrl- A. Opening the door to other commands to run while the dialog is up seems like it's asking for trouble. What if the other command popped a dialog on its own? Will the heuristic to determine what's a dialog and what's a window always work? I'm having a hard time thinking of cases of global commands that would be useful to run while a dialog is up.
In my experience with Eclipse development (which is admittedly, fairly limited), one of the big problems I've seen to date is APIs and functionality that has been "under designed": not flexible enough, not powerful enough, too specific to the initial problem being solved. I didn't want to make the same mistake, if it could be avoided. So, I wanted to leave the power in the hands of the developers -- to decide how they want to use it. For example, debug is already trying to define key bindings that are available in particular dialogs that they open -- a use that I had not originally envisioned.
I still don't see why extra contexts are necessary. If the dialog could get a command service (or key binding service) for the dialog, then it would just register the commands it cares about. I wouldn't expect dialogs to pick up commands from the parent window to begin with, if that's the problem the extra contexts are trying to address.
How can I find out using the Keys preference page which commands are available in a given context, e.g. dialog?
Dani: No, I don't believe so. Please add your usability comments to Bug 43506.
Verified that switching to Emacs and pressing "Ctrl+W" cuts the select text in a dialog. Verified in I200403240800.
Reopening: I'm trying I200403240800 now and although you fixed Ctrl-A you broke Ctrl-Z (and Ctrl-Y) and Del and maybe others (see bug 55181 for a list of some of what was working and not working before). This is on Windows XP. I do not agree with this change. Here are some reasons: 1. Disabling all the native accelerators and trying to re-add them by hand will cause problems like the ones above. 2. Having Ctrl-W do a cut in emacs mode is just strange. Emacs mode should just affect the editor. I always hold up Textpad as a good example of a native editor, and its key definitions are completely seperate from the keys recognized in dialogs. 3. You can totally screw up your key definitions and have no way to fix them without using the mouse if the dialogs honor those same key definitions. 4. Platform consistency. Every Windows app honors the Del key to delete a character and Ctrl-C to copy in a dialog. Every Mac app honors certain keys too. 5. Consistency within the application. Fully native dialogs cannot honor these key definitions. For example, try File > Open External File. Even in this new build the Eclipse key definitions are not honored there. Please consider backing out this change at least until all the ramifications can be worked out.
Bug 55181 was reported in many duplicate forms, and has been fixed in I200403250010. 1.) Every emulated widget (e.g., StyledText) already emulates native key bindings, and they do it well. 2.) The default is that a user of the Emacs key binding set will have "Ctrl+W" in dialogs. However, the user has the power to change this. Simply map "Ctrl+W" to "Editing Text", and map "Ctrl+C" to "In Windows and Dialogs". 3.) Can you give me the steps to reproduce? 4.) Some Emacs users I know consider it a platform onto itself. While the default behaviour should be as close to native as possible, the user should have the power to make their working environment match their needs. 5.) Fully native dialogs can honour our key bindings. Check out "Ctrl+W" using the Emacs key configuration in the "File > Open External File..." dialog.
Verified, as mentioned before.
I200403250800 See esp. (1) and (5) below: 1.) Ctrl-Z and DEL are working now but not Ctrl-Y (redo). 2.) Ok, I don't agree with that default but we can agree to disagree if I'm in the minority. 3.) No, it was just theoretical. I don't want to screw up my key bindings that bad. 4.) See (2) 5.) I tried exactly those steps and it does NOT work for me. I'm running on Windows XP SP1, JDK 1.4.2_04, and I have a manifest file. In Emacs mode, the Open > Open External File dialog does NOT accept Ctrl-W, and in regular mode it doesn't accept Ctrl-A (which, if you think about it, is very ironic :). If this is supposed to work let me know if you need any more info to reproduce it.
1.) I ran with I200412162000, and "Ctrl+Y" didn't work in the open external editor dialog. Perhaps redo is not supported by native widgets? Perhaps this is something our dialog support could add? I'm guessing from you bringing it up, that this is something you'd find useful? 5.) You're right. Please open a separate bug, assign it to me, prefix it with "[KeyBindings]".
1) Ok, I must have been hallucinating. Nevermind about Ctrl-Y. 5) Bug 56223
*** Bug 49957 has been marked as a duplicate of this bug. ***
