Community
Participate
Working Groups
We should remove the "Export..." button on the Preferences..Keys page, since the exported file is not importable. This would reduce confusion for users who are trying to export the key bindings, expecting that that there's a way to import them.
We've renamed this to 'Export CSV...' in 3.5. Maybe we need to rename it again?
No, it's just that the Export feature is vestigial, that is, in older versions of Eclipse you could export key bindings and import them from this page. With current versions, the Import is gone but the Export is still there. So, it seems like we could get rid of the Export option entirely, since there's no longer any reason to export key bindings.
This is very confusing UI plus it is extremely frustrating when you find out you lost everything from this broken design.
I agree it's confusing, but we can't just remove the functionality. There were many bug reports that asked for it, see bug 37439. Maybe we can revive the 'Advanced' button we had in 3.3 and move the filters back in there plus a button that allows to show the key bindings in a dialog or, copy them into the clipboard.
The problem was not about being able to see the key bindings, but the export button. This give the possibility to export your keybindings, but there is no feature to import them back. This means that the export functionality is useless.
(In reply to Francis Lavoie from comment #5) > The problem was not about being able to see the key bindings, but the export > button. Yes it was, at least in some of the duplicates of bug 37439.
(In reply to Dani Megert from comment #6) > Yes it was, at least in some of the duplicates of bug 37439. Lets make this button only about the removal of the export button.
(In reply to Lars Vogel from comment #7) > (In reply to Dani Megert from comment #6) > > Yes it was, at least in some of the duplicates of bug 37439. > > Lets make this button only about the removal of the export button. You can't remove it without keeping the functionality that was added for bug 37439. If you want to restrict this bug to the removal, then I have to close it as WONTFIX.
> in older versions of Eclipse you could export key bindings and import them > from this page. Import was never available through that page. Export was really just added to give people the ability to get all shortcuts in a text file. I agree that the name is misleading, hence the suggestion to move it into an 'Advanced' section. I'm also fine just renaming the button, if we find a good and short name.
(In reply to Dani Megert from comment #9) > You can't remove it without keeping the functionality that was added for bug 37439. Make sense, I agree after reading Bug 37439. Now that I know why this button was added, I think the name of the button is pretty good. Maybe we simply describe the intention of this button in the help section? http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Fconcepts%2Faccessibility%2Fkeyboardshortcuts.htm&resultof=%22keybinding%22%20%22keybind%22 > I agree that the name is misleading, hence the suggestion to move it into an > 'Advanced' section. -1 I think that would not be beneficial to the user. Advanced sections make IMHO the UI less efficient.
(In reply to Lars Vogel from comment #10) > -1 I think that would not be beneficial to the user. Advanced sections make > IMHO the UI less efficient. Yes, I generally agree to that. Another solution would be to allow multi-select on the table and add a 'Copy to Clipboard' to the context menu. Updating the doc doesn't really bring any value for the user I think.
(In reply to Dani Megert from comment #11) > Another solution would be to allow multi-select on the table and add a 'Copy > to Clipboard' to the context menu. > Updating the doc doesn't really bring any value for the user I think. I agree, but given our current platform.ui worklist it seem unreasonable to put in development effort into this tiny feature (which I personally have never used or noted). So a fast "win" would be have a pointer for the user, without spending valuable development time on it.
(In reply to Lars Vogel from comment #12) > (In reply to Dani Megert from comment #11) > > Another solution would be to allow multi-select on the table and add a 'Copy > > to Clipboard' to the context menu. > > Updating the doc doesn't really bring any value for the user I think. > > I agree, but given our current platform.ui worklist it seem unreasonable to > put in development effort into this tiny feature (which I personally have > never used or noted). Right, that's why I would never have started to touch this ;-).
(In reply to Dani Megert from comment #13) > Right, that's why I would never have started to touch this ;-). IMHO a wontfix is better for the bug reporter than a long outstanding bug, if their are no plans to fix this item. IIRC this bug also made it to the Eclipse 4.5 prio list (how did that happen?) I mark this as wontfix, assuming that you agree that we will not spend dev effort on this in the foreseeable future. Also in this particular case the suggested solutions are IMHO not adding "real" value to the user. I also open a new bug to update the help system (current screenshot is also outdated), at least we have than something to point users too.
(In reply to Lars Vogel from comment #14) > (In reply to Dani Megert from comment #13) > > Right, that's why I would never have started to touch this ;-). > > IMHO a wontfix is better for the bug reporter than a long outstanding bug, > if their are no plans to fix this item. IIRC this bug also made it to the > Eclipse 4.5 prio list (how did that happen?) It's on position 311 if that matter. Someone probably voted for it.
