Community
Participate
Working Groups
I20070503-1400, follow-up to bug 184421 The platform now logs detected keybinding conflicts from declarations in plugin.xml. (Inconsistency: you only log conflicts from plugin.xmls where the user has not resolved the conflict manually, but you don't log conflicts that the user produced). Such conflicts will inevitably emerge in practice if users install plug-ins from different sources, so it's not a good idea to log them again and again at each startup. Better solutions would be to - log only once after new plug-ins have been installed, or - not log at all but improve the Keys pref page to make conflicts apparent (bug 185518). !ENTRY org.eclipse.jface 2 0 2007-05-04 10:26:51.125 !MESSAGE Keybinding conflicts occurred. They may interfere with normal accelerator operation. !SUBENTRY 1 org.eclipse.jface 2 0 2007-05-04 10:26:51.125 !MESSAGE A conflict occurred for ALT+SHIFT+Q Z: Binding(ALT+SHIFT+Q Z, ParameterizedCommand(Command(org.eclipse.team.ui.GenericHistoryView,History, Show the Team History view, Category(org.eclipse.ui.category.views,Views,Commands for opening views,true), org.eclipse.ui.internal.registry.ShowViewHandler@7d5b1a, ,,true),null), org.eclipse.ui.defaultAcceleratorConfiguration, org.eclipse.ui.contexts.window,,,system) Binding(ALT+SHIFT+Q Z, ParameterizedCommand(Command(org.eclipse.jdt.jeview.views.JavaElementView,JavaElementView, JavaElement View, Category(org.eclipse.ui.category.views,Views,Commands for opening views,true), org.eclipse.ui.internal.registry.ShowViewHandler@1e81bb3, ,,true),null), org.eclipse.ui.defaultAcceleratorConfiguration, org.eclipse.ui.contexts.window,,,system)
Created attachment 66310 [details] Different approach v01 (draft) A different approach: Instead of logging conflicts, we will notify the user (popup, status line, something) if they select a key that is in conflict from the current active bindings. If the user never selects that key, they'll never see the warning (both a plus and a minus). PW
Created attachment 66360 [details] Status line approach v01 This removes logging and warns the user on the status line in the same "bit" we use to display partial keybindings. Good: 1) no popup disrupting workflow 2) no log message So-So: 1) The message itself will never be wholy visible, you have to hover to be able to see it. PW
Why the different approach? As a programmer (not user) of a plug-in I would like to immediatley get the conflicts reported and be forced to test everything manually to get the message. Can't you remember which conflicts you logged?
(In reply to comment #0) > I20070503-1400, follow-up to bug 184421 > > The platform now logs detected keybinding conflicts from declarations in > plugin.xml. (Inconsistency: you only log conflicts from plugin.xmls where the > user has not resolved the conflict manually, but you don't log conflicts that > the user produced). It logs user conflicts. The only case that it won't log is where a user binding overrides a system binding (since it will actually let the user binding win). PW
Created attachment 66535 [details] Key Assist v03 (draft) Here is another option. Logging the errors once per session remains intact. But when the user tries to use a conflicted key, the key assist dialog pops up with the choices ... same behaviour as CTRL+SHIFT+Q and then wait. PW
bug 186403 is used to track the User Feedback ramblings of this bug. I'd consider some more logging enhancements post-3.3 PW
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.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
