Community
Participate
Working Groups
Safari uses COMMAND+LEFT/RIGHT_ARROW for navigation history. Eclipse uses ALT. I don't think this is consistent with other Mac applications.
So, COMMAND+LEFT is mapped to Previous Word. this is also backwards. ALT+LEFT should be previous word, or at least that is the platform behavior for the text control I am typing in right now.
Yes, I am aware of these differences, but our Mac person at the time (Chris McLaren) said that making these changes was not a good idea. I can't remember exactly why. What does Xcode use? "http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGKeyboardShortcuts/chapter_20_section_1.html" Kim: What do you feel about this?
I'd prefer if we kept navigation to alt, or at least, not map it to command. XCode uses command-left/right for navigating within the editor, as do most text widgets/apps, although it usually means beginning of line/end of line, not previous/next word.
What key does Firefox use on MacOS X?
3rd-party keybindings are not relevant here. Finder uses COMMAND+LEFT/RT_BRACKET for navigation history. Safari uses COMMAND+ARROW. We need to just pick one of these. Personally, I don't think that platform's duplicate keybindings for HOME and END are worth preserving. But, you could provide both keybindings, and have text editors override the duplicate HOME and END keybindings in their more restrictive context. Every native text control, Stickies, TextEdit, Input fields in web Browsers, etc., all use ALT+LEFT_ARROW to mean previous word. Felipe, what does plain vanilla StyledText use for prev word?
StyledText: setKeyBinding(SWT.ARROW_LEFT | SWT.MOD1, ST.WORD_PREVIOUS); setKeyBinding(SWT.ARROW_RIGHT | SWT.MOD1, ST.WORD_NEXT); MOD1 = COMMAND;
(In reply to comment #6) > StyledText: > setKeyBinding(SWT.ARROW_LEFT | SWT.MOD1, ST.WORD_PREVIOUS); > setKeyBinding(SWT.ARROW_RIGHT | SWT.MOD1, ST.WORD_NEXT); > MOD1 = COMMAND; then StyledText is not consistent with Text. Should I open a separate bug?
As a long time mac user and eclipse user I would be happiest if the Apple HIG were followed as per the link in comment #2. The very first thing I do when I create a new workspace is change to these key mappings. In particular: COMMAND+LEFT beginning of line COMMAND+RIGHT end of line ALT+LEFT beginning of current word and then beginning of previous word ALT+RIGHT end of current word and then end of next word Holding down the SHIFT key with any of these combinations causes the text to also be selected. This has been the MacOS standard since 1986 - when a Mac keyboard first shipped with arrow keys.
Andre: Can you comment on this bug please?
Comment #8 sounds like it has good default values for text widgets. Would using these require both UI and SWT changes? Re: "Safari uses COMMAND+ARROW." in comment #5: Safari also works with COMMAND+LEFT/ RT_BRACKET, so this seems like a good choice for navigation history.
The changes would like be more extensive then that. To bring our text selection and navigation keys in line with the guidelines, we'd have to do more than just those four keys. Basically, just look at the arrow keys in the link in comment #2. This would require changes to SWT and likely Platform Text as well. Perhaps something to try playing with early in 3.2 ... to give us a chance to see how our users respond?
SWT should change first, then Text and Workbench components should match.
Are we really changing this for 3.1 ? IMO, we still have 4 weeks Doug, if we put this code in for RC1 and people hate us you can remove it before RC2. Steve, should I just go ahead and fix bug 96615 ?
Woh! Read comment #11 again! I said 3.2 not 3.1....
Doug and McQ: Do you want us to make the SWT changes? Sounds like "no" from Doug.
Platform L&F, platform L&F, platform L&F... Users might be annoyed at first, just like when trying to invoke content assist in recent builds. I don't think the question is how many users will be annoyed. It's the right thing to do, so the only question is how much risk is involved.
No way! I actually agree with Randy. ;-) If the risk is low, I vote that we fix this. Every release we wait makes it harder to change.
Doug? We have the SWT changes ready. If you think that this is too dangerous, we will hold them back. Personally, I wouldn't make a change like this to Eclipse at this late date.
AFAIK, unlike the SWT change, this is just a change in the plugin.xml file. There are already some Mac-specific entries for keybindings like code assist.
(Sorry, I was on vacation) but I agree with McQ (comment #17). Let's fix this now. The risk looks low to me.
I'm still generally concerned about making user interface changes to so many fundamental key bindings this late in the development cycle. It gives our user base little time to react if it causes any kind of problem.
So the summary is Steve and Doug feel it is too much risk, All Mac users who've commented except for Kim want it to happen. If you were to do this Doug, do you have a clear idea of what you would change?
The "plugin.xml" files for the following projects would need to change: + org.eclipse.jdt.ui (6) + org.eclipse.ui (2) + org.eclipse.ui.workbench.texteditor (10) The changes to UI code are quite simple, but the changes to JDT/UI and Platform/Text would require some more time to do properly. The problem is finding the most appropriate command to emulate native behaviour. This would likely require some tinkering with Xcode and the Mac text editor. All tolled, there are 18 bindings that would need to be revisited.
Doug, in Bug 96615 I listed the binding I'll change in StyledText to fix the bug. Could you check that and make sure that is the right thing ? Ps. I have the fix ready in my workspace, let me know when to release it.
> Platform/Text would require some more time to do properly. The problem is > finding the most appropriate command to emulate native behaviour. This would XCode? We have already confirmed the native keybindings ad nauseum. According to comment 8 they have not changed in 19 years. Here's a snippet if you want to confirm them manually: Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); new Text(shell, SWT.MULTI | SWT.V_SCROLL); shell.open(); while (!shell.isDisposed()) if (!display.readAndDispatch()) display.sleep();
This is what I've been able to glean from using Xcode and the text editor. PageUp, PageDown Does not change cursor position, but scrolls the window (with shift) Moves cursor by one page with reducible selection Home, End Does not change cursor position, moves to beginning/end of window (with shift) Same as above with non-reducible selection Cmd+Up/Down Moves cursor to beginning/end of document (with shift) Same as above, but with non-reducible selection Cmd+Left/Right Moves cursor to beginning/end of line. If pressed multiple times, this will not continue to another line. (with shift) Same as above, but with non-reducible selection Opt+Left/Right Moves cursor one word forward/back (with shift) Same as above with reducible selection Opt+Up/Down Moves the cursor to the beginning/end of the next wrapped line (with shift) Sames as above with reducible selection Opt+PageUp/Down Moves the cursor up/down a page. "Reducible" selection is a selection which can be shrunk by pressing the opposite key. So, pressing "Opt+Shift+Left" and then "Opt+Shift+Right" will leave the selection in the same state. "Non-reducible" selection is a selection where the opposite key simply extends the selection further. For example, pressing "Cmd+Shift+Up" will select everything from the cursor to the beginning document. Then pressing "Cmd+Shift+Down" will extend the selection to include everything from the cursor to the end of the document (i.e., the whole document will now be selected). I'm not sure how attached a Mac user would be to the concept of reducible vs. non-reducible selection. Xcode does not appear to do anything interesting with the logical units that exist within a Java file. So, while we have commands to select parent elements or next element, Xcode does not.
Can we get these cleaned up in 3.2?
I have no plans to address this for 3.2.
*** Bug 125817 has been marked as a duplicate of this bug. ***
Eclipse is nearly unusable on the Mac because of this bug...the key bindings are all wrong, so I constantly find myself suddenly transported to an entirely different place in the file, even though I just wanted to move by a word or two. Can't this be fixed? You need to follow Apple's interface guidelines.
I've changed some of the most annoying wrong bindings (Cursor movement) and provided the prefs with installation instructions on my site. http://www.martinkahr.com/2006/02/13/mac-keys-for-eclipse/ Hope this helps some people until this "bug" is fixed.
Guys, this is really easy to provide a patch for. Why doesn't someone who uses Mac regularly checkout org.eclip.ui.texteditor, and make the necessary changes to plugin.xml, and submit the patch?
Created attachment 36318 [details] Fix Randy, it's not done with a quick hack in a single plugin.xml. The fix needs to take into account all keybindings with modified arrow keys, as well as Home/End and Del/Backspace to ensure a consistent and overlaps-free story that matches Mac platform conventions as close as possible. And it must work the same for pure StyledText as for AbstractTextEditor. This patch should solve all these problems. It's a workspace patch with changes for (org.eclipse.)swt, ui, ui.workbench.texteditor, jdt.ui. If you have any objections to the patch, *please speak up now*. Otherwise, I'll push for getting this into M6, since the current bindings are really unusable for keyboard navigators who are used to 20 years tradition (-> comment 8). Steve/Felipe, Doug, Dani: Please arrange to commit your respective portions together with the other parts for the same nightly build.
Created attachment 36320 [details] Cheatsheet to find bindings FWIW, here's my cheatsheet (OpenOffice.org 1.0 spreadsheet) Most important changes for carbon (other platforms unchanged): - word-wise navigation uses Option (old: Command) - Command+Left/Right jumps to start/end of line (old: Home/End) - Navigate > Back/Forward is Command+[/] or Command+Alt+Left/Right (old: Option+Left/Right; Apple has no consistent story here that works across locales) - Home/End and Command+Up/Down jump to start/end of document (old: Command+H/E) - scrolling line-wise is Ctrl+Up/Down (old: Command+Up/Down) - (Java Editor) Edit > Expand Selection... is Ctrl+Shift+Up/Down/Left/Right (old: Shift+Option+U/D/L/R) - (Java Editor) navigate to Next/Previous member is Ctrl+Alt+Up/Down (old: Ctrl+Shift+U/D)
I've verified the patch and it works as advertised (even on a Swiss-German keyboard thanks to Markus' careful chosen alternate bindings). So I think this would be a fine addition to 3.2M6 for MacOS...
+1 for the proposed changes in Platform Text and JDT Text.
SWT and Platform/UI: are there any objections, or would you agree to release your parts for 3.2RC1?
I think this patch should be released for RC1. There have not been any objections to the proposed alignment with native MacOS keybindings, and the earlier it goes into the build, the better we can react to problems (although I don't expect any).
The only objection that we have is that these changes capture only some of the special Mac key sequences, not all of them. It's too late to try and do them all for 3.2. Are we OK with this?
These changes handle all navigation key sequences and make them as native as possible. I didn't include changes to other keys (help, insert, F-keys, ..) on purpose, because I think those are not as pressing as navigation keys, and they are pretty independent of the navigation key fixes.
Steve, I have no objections against this partial solution, because it addresses the 95% case.
I am ok with this. There are two issues: 1) for the set of things that the editor supports, are we using the matching mac keys? 2) are we supporting all possible mac features? This addresses 1) and that seems obviously good. We should still consider looking at 2) post R3.2.
Shall we go ahead then? FH has the SWT code in hand.
+1. ok to proceed.
For me very fine, apart from one additional (non-navigation) request perhaps: from a user's perspective, quick fix is used A LOT. Due to it's extensive usage, it is perhaps worthwhiel including that as well alreeady? (Or has this been covered already with this solution?) Phil (In reply to comment #43) > Shall we go ahead then? FH has the SWT code in hand. >
paul could you apply the patches?
regarding comment #45 please log a new bug...
Paul: I talked to Dani today and we decide to fix this problem for RC2. I'll release my part of the code today (it won't make it for RC1 cause we tag our code yesteray). The thing is, please *do not* release any code till we (Dani and me) are ready. Thanks.
OK, I'm sitting on the Platform UI part of the patch until I get the go ahead. PW
Paul, I suggest that I take over the whole rest of the patch. I can then test and release it altogether (I'm used to change things in org.eclipse.ui/plugin.xml since several text commands are in there as well).
Dani, sure, just let us know when it's released. PW
Felipe, please reassign to me (in Platform Text) once the SWT part is released.
Okay, I have the code ready and tested, just have a couple notes: First: For example: setKeyBinding(SWT.HOME, ST.TEXT_START); setKeyBinding(SWT.END, ST.TEXT_END); setKeyBinding(SWT.COMMAND | SWT.ARROW_UP, ST.TEXT_START); setKeyBinding(SWT.COMMAND | SWT.ARROW_DOWN, ST.TEXT_END); Here we have HOME and COMMAND + ARROW_UP mapping the same action (TEXT_START), in the real world HOME and CMD+ARROW_UP are not exactly the same, both will cause the editor to scroll and show the beggining of the doc but HOME does not move the caret while CMD+ARROW_UP does. They have the same thing for page_up, (page_up scroll, page_up scroll and move caret), and line_up too I think. StyledText does have that notion, it always scrolls and updates the caret along. Second: setKeyBinding(SWT.DEL | SWT.SHIFT, ST.DELETE_NEXT); Is that really necessary ?
Release my part of the fix. StyledText implements the exact functionality found in the patch attached in comment #33.
Markus, please answer Felipe's questions.
Thanks a lot, Felipe! > StyledText does have that notion, it always scrolls and updates the caret > along. Yes, I realized that StyledText does not support all actions available on MacOSX. However, scrolling without moving the caret has never been available up to now, so this is not a regression. The decision was only between mapping the keys to similar action, or to leave them unmapped -- and I think it's better to have them mapped for now. People can file a new enhancement request if they want StyledText to support the scroll-only actions as well. > Second: > setKeyBinding(SWT.DEL | SWT.SHIFT, ST.DELETE_NEXT); > > Is that really necessary ? I think that's the default on MacOSX, and it would be in line with Shift+BS doing the same as BS. I don't have a Mac here right now, but I'll recheck this evening and post the results.
Released remaining parts of the patch. Available in builds > N20060418-0010.
Created attachment 39150 [details] Fix for multiply-bound keys on carbon I rechecked, and found that Shift+DEL for DELETE_NEXT is available in most Mac applications. I think we should leave that support in as well. Here's a last patch against HEAD of ui.workbench.texteditor. I missed to explicitly remove some keybindings on carbon. At least in latest builds, conflicting bindings are created when a second binding is defined for an already bound key sequence. The fix is to remove the general bindings for a command by adding a keybinding with an empty commandId. Dani, could you please release?
Reopening.
Patch released. Available in builds > N20060421-0010.
Verified in N20060425-0010 that navigation, selection, and deletion keybindings on carbon adhere to platfom conventions in vanilla StyledText, text editor, and Java editor, and that keybindings can be remapped.
After switching to RC2 nearly all key bindings for text editing changed on my mac. After some really annoying hours I got a hint to this bug. There a lot of developers out there which develop on several platforms. As a consequence learning two bindings is no fun. I tried to adapt the bindings to the old values, but I can't find commands in the preferences for all text editing shortcut. If there is no chance for users to use same bindings for both platforms, this is really not funny. For me (and my teammates) the decision is clear: I will not use RC2 and hope there will be a chance to configure ALL bindings to old values manually. Otherwise I won't use the 3.2 Release either because it's two hard to learn to shortcuts and always remember what shortcut for what platform.
> There a lot of developers out there which develop on several platforms. > As a consequence learning two bindings is no fun. -- The fact is different platforms have different key bindings, nothing one can do about that. Simple "copy" is Ctrl-C on a PC, "Cmd-C" on a workstation. Eclipse wishes to be (with good reason) a true OSX citizen as well and it can only be that if it also uses the platforms's Key Bindings. These are the differences that truly set it out. If Eclipse wouldn't use the Mac bindings, it wouldn' t be a Mac App. It would be a good as a document translation made by a computer, the native feeling's gone. These efforts are bliss. For me it's the best new feature of 3.2 and our devs just love it. We in fact always immediately download the last versions, just for the key bindings! (care even less about other remaining bugs!) That aside, perhaps for people like you who wish to ignore the actual platform, bundles of keybindings could be defined and assigned in the prefs window. Than I can use all my Mac bindings should I ever be foced to use PCs for development ;-) The work done so far is great, I am very thankful for it. Phil
The Mac keybindings were changed to meet the expectations of Mac developers, not the expectation of windows developers who have to do occasional testing on the Mac. You should be able to change most source editing bindings in the preferences dialog, but native text widgets throughout Eclipse have always used, and will continue to use the Mac accelerators.
You are all right making eclipse feel more like a native app. But I think it's important to give users the chance of choice. Within RC2 there were some commands missing and it was not possible to configure a shortcut I am using every minute. Today I downloaded RC3 and the missing commands are added. Thanks a lot for adding the commands and giving developers who are working on multiple plattform the possiblity to configure same shortcuts on both machines.
> The Mac keybindings were changed to meet the expectations of Mac developers, > not the expectation of windows developers who have to do occasional testing on > the Mac. Just a comment: I'm not a window developer who does occasional testing on a Mac. Perhaps I'm belonging to a minority of developers who really uses eclipse on more than one platform (at least in the company I am working are a several other developers) and changing basic shortcuts without alternative would decrease productivity.
(In reply to comment #66) > Just a comment: > I'm not a window developer who does occasional testing on a Mac. > Perhaps I'm belonging to a minority of developers who really uses eclipse on > more than one platform (at least in the company I am working are a several > other developers) and changing basic shortcuts without alternative would > decrease productivity. > Hi Vera. No offense meant but I truly think this is indeed a very rare situation. It is already rare that devs would use different computers to get their work done (devs mostly are quite picky when it comes to tool set, various setup issues (both OS-wise and tool -wise & ... ) Heck I've had debates here on guys changing the desktop pictures! So even when this would happen, if on top of that you're mixing platforms... well, then you deserve a different key binding! ;-) All jokes aside Vera: truth is the very priority is to make Eclipse a true OS-citizen on all supported platforms. That means proper Key Bindings. Period. (hence my iternal gratitude for this change) If on term, it would be so that any Eclipse app would be bundled with all platform key bindings as a "named set" that you can assign/pick at runtime - fine for me. Doens't break rule Nr1. But if that is too much pain for the 0,0001% of users that would benefit from it - I can live with its absence. Peace, Phil
*** Bug 107414 has been marked as a duplicate of this bug. ***
I was not aware of this bug when I filed Bug 150087. I think the changes in Comment #34 are a bad idea since history isn't accessible any more at all on a German keyboard. Gerd
(In reply to comment #69) > [..] history isn't accessible any more at all on a German keyboard. It is accessible, see comment 34: > - Navigate > Back/Forward is Command+[/] or Command+Alt+Left/Right Please continue discussions on this issue in bug 150087.
