Community
Participate
Working Groups
now that we have some keybinding support in the command framework, we'll want to go back and visit all our commands to decide: - should there be a keybinding and what binding should it be - ensure the command name is a good user name (it will show in the key assist dialog) - ensure all commands have tooltips (the tooltip can be shown as a description in the key assist dialog even if the command is rendered such that a tooltip is never shown) It just occurred to me that we should call "Open Resource" something better like "Find File". There may be other names that need revisiting. Also need to check for consistent case, etc.
I'll make a pass during RC1 to ensure everything gets a binding. However, anyone who wants to add bindings now to their pages is free to do so. Take a look at fileCommands.js and globalCommands.js for examples. The keybinding is specified when the command contribution is registered, and you can optionally specify that a command is "keyOnly" which means it will never be rendered in the UI. Make sure that you don't use any bindings already used in globalCommands.js
Is there some way to see what the bindings are from the UI?
(In reply to comment #2) > Is there some way to see what the bindings are from the UI? Yes, type '?' and you'll see the keyassist popup from the orion logo. I still have some work to do, it is itemized in bug 334200 comment 9 (at the end of that comment)
Bug 334200 is now fixed. Key Assist Panel is accessible through '?' key on any page. From the editor, you need to use "Ctrl+Shift+?" - All the editor bindings are now showing in the key assist panel (good). - Hard to escape out of the key assist panel if you launched it from the editor. You need to put focus elsewhere and press Esc. (bad) Opened bug 347875 for this problem. Something to think about as we create bindings. We currently bind Open Resource to "Ctrl+Shift+R" when inside the editor (the eclipse binding) and "T" when outside the editor (the github binding for similar function). I'm leaning toward changing the open resource binding in the editor to "Ctrl+Shift+T" for consistency. If anyone has objections let me know. For the remaining bindings I will try to pick the eclipse equivalent if it makes sense or find a web variant.
(In reply to comment #4) > Something to think about as we create bindings. > We currently bind Open Resource to "Ctrl+Shift+R" when inside the editor (the > eclipse binding) and "T" when outside the editor (the github binding for > similar function). I'm leaning toward changing the open resource binding in the > editor to "Ctrl+Shift+T" for consistency. If anyone has objections let me > know. Maybe I'm doing something wrong, but I can't for the life of me get Ctrl+Shift+R to work from the editor-- it just reloads the page. I agree with changing it. The only issue I have with Ctrl+Shift+T is that it conflicts with another browser hotkey (Reopen Closed Tab).
(In reply to comment #5) > Maybe I'm doing something wrong, but I can't for the life of me get > Ctrl+Shift+R to work from the editor-- it just reloads the page. There was a missing require js dependency in OpenResourceDialog. On pages that already required dijit.form.Text the dialog worked, but pages that did not already require it, it was broken. Fixed. >I agree with > changing it. The only issue I have with Ctrl+Shift+T is that it conflicts with > another browser hotkey (Reopen Closed Tab). We already have some browser binding conflicts (such as Ctrl+/ for toggle comment and FF uses it for Add-On Bar) but I do agree we want to try to avoid conflicts with the most common bindings, esp those that are the same across browsers. Maybe F (and Ctrl+Shift+F in the editor) for "Find File..." That would still leave Ctrl+F for Browser find...
One other issue I found: 1. From JS editor, hit Ctrl+Shift+/ (used to be "Add Block Comment") 2. The Key Assist panel pops up.
Susan, note that I moved orion.textview.KeyBinding (was eclipse.KeyBinding) to a separated file. So you can use it without having to import the TextView. See Bug 347826 for details.
(In reply to comment #0) > now that we have some keybinding support in the command framework, we'll want > to go back and visit all our commands to decide: > > - should there be a keybinding and what binding should it be > - ensure the command name is a good user name (it will show in the key assist > dialog) > - ensure all commands have tooltips (the tooltip can be shown as a description > in the key assist dialog even if the command is rendered such that a tooltip is > never shown) Opened bug 349602 for these items. We are not claiming accessibility in the 0.2 release. So the task in this bug is to clean up the problematic bindings rather than add new ones. - Rename "Open Resource" to "Find File" This was already done. I also considered switching the editor binding used here. Cmd+T is the textmate binding, but that is "open tab" in browsers. Moving to "F" (Ctrl+Shift+F in the editor) for "Find File..." doesn't match any other precedents, and while it kind of goes with the well known Ctrl-F for find, I didn't like the idea of overloading the F. So in the end, I'm leaving this alone for now and using the eclipse keybinding (ctrl+shift+r). - Continue to use "?" for key assist outside of the editor. However within the editor, Ctrl+? (which is actually Ctrl+Shift+/) conflicts with "Add Block Comment". Too bad, because Cmd+Shift+/ is often associated with help on the Mac (says Boris). But we don't know a well-known "show keys" binding beyond "?". Since we don't have a good answer, I am again going with the eclipse binding for lack of a better one. (ctrl+shift+l)
This was a lot more thinking than coding. One line change. http://git.eclipse.org/c/e4/org.eclipse.orion.client.git/commit/?h=XX347248 Or check out remotes/origin/XX347248 Adding Mark for review.
+1
pushed. (the version of the file I pushed also had a CSS width change as part of some polish I'm doing with Linda in bug 344895.)
