This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
http://deadlock.netbeans.org/hudson/job/javadoc-nbms/1783/testReport/org.netbeans.core.projects/ValidateLayerConsistencyTest/testIfOneFileIsDefinedTwiceByDifferentModulesTheyNeedToHaveMutualDependency/ junit.framework.AssertionFailedError: Some modules override their files and do not depend on each other Shortcuts/OS-S.shadow is provided by: [org.netbeans.modules.codetemplatetools/1, org.netbeans.modules.perspective/1] org.netbeans.modules.codetemplatetools/1: different attributes = '{originalFile=Actions/Edit/org-netbeans-modules-codetemplatetools-actions-SurroundWithAction.instance} org.netbeans.modules.perspective/1: different attributes = '{originalFile=Actions/Perspective/org-netbeans-modules-perspective-actions-QuickSwitch.instance}
I guess this an issue of conflicting shortcuts between two contribed modules. A particular user may not install bothe these modules? What is the mechanism to resolve this kind of conflict?
Right, if someone installed both then some functionality would be lost. There is no formal mechanism to resolve the conflict; you need to either change your own shortcuts, or ask the owner of the other module to do so. Of course keyboard shortcuts are precious resource so you should not create any unless you expect the functionality to be constantly in use.
Snippet from Eclipse Help about this issue: The Dynamic Nature of Key bindings Key bindings are provided by plug-ins, and in Eclipse, plug-ins can be added or removed. This can cause key bindings declared by these plug-ins to be added or removed. Eclipse stores custom key bindings in a way to compensate for this. Consider the example above where Ctrl+Alt+W was assigned to Cut in the Emacs scheme. Say you install a new plug-in that assigns Ctrl+Alt+W to a particular command. Eclipse will preserve your assignment to Cut. Conflict Resolution There are only a finite number of simple, common key strokes available to assign to a multitude of commands. We have seen that scheme, context, platform, and locale all partition key sequence assignments into domains where they don't conflict with one another. Consider the case for Ctrl+B above if contexts did not exist. One plug-in would assign Ctrl+B to Build, the other plug-in would assign Ctrl+B to Make Bold Text. How would Eclipse properly resolve this conflict? Though conflicts are drastically reduced by employing the above mechanisms, they can still occur. Two plug-ins, independent of one another, could assign the same key sequence to different commands with the same context, scheme, platform, and locale. Consider if a plug-in assigned Ctrl+F4 in the In Windows context and Default scheme to one of its commands. This directly conflicts with Eclipse assigning Ctrl+F4 to the close command in the same context and scheme. This is a conflict. It wouldn't be proper to invoke both commands, nor would it be proper to simply choose one of the two commands to receive the key stroke. The only proper thing to do is to ignore both key bindings, making Ctrl+F4 effectively useless in this context and scheme. These types of conflicts can be resolved by explicitly assigning the key sequence to one of the commands. Another type of conflict can be caused by multiple-key stroke key sequences. For example, in the Emacs scheme, there are many multiple-key stroke key sequences beginning with the key stroke Ctrl+X. Ctrl+X K is assigned to Close. Ctrl+X H is assigned to Select All. As previously mentioned, the Emacs scheme borrows key bindings from the Default scheme. In the default scheme, Ctrl+X is assigned to Cut. Though the Emacs scheme doesn't explicitly redefine Ctrl+X, pressing Ctrl+X is required as part of many of its key bindings. In the Emacs scheme, when one presses Ctrl+X, one is half way to entering one of many possible assigned key sequences. One would not expect the Cut action to be invoked at this time. For this type of conflict, the rule is that the Ctrl+X key sequence assigned to Cut would be ignored. Otherwise, it would not be possible to complete many of the key bindings in the Emacs configuration.
Other possible enhancement is that when the user invokes such a conflicting key binding (sequence) a pop up could be shown with entries like: Tools:Options:KeyMap Key Stroke(s) - Action 1 Key Stroke(s) - Action 2 Key Stroke(s) - Action 1 (keep) Key Stroke(s) - Action 2 (keep) Key Stroke(s)...more Then the user can either choose one of the conflicting actions, type more keys to get out of prefix conflict or be taken to the Tools:Options:Keymap to fix the conflict. I will file the enhancement request.
Such an enhancement might be useful, but it presupposes an API change (issue #15926) to make it even possible for multiple modules to register the same shortcut.
See: http://www.netbeans.org/issues/show_bug.cgi?id=135842
Still broken, are you fixing? Should be a trivial matter of removing the shortcut from one or the other module.
I know removing the shortcut is trivial. The question is from which module? Adding theanuradha for opinion. I am not fully convinced that this is bug. That is because this situation can occur with modules coming from different sources. IMHO the NetBeans platform should detect and handle such situations gracefully and at minimum inform the user of such conflicts (possibly non-intrusively i.e. avoiding modal dialogs) and even better to assist the user in fixing the issue (as described in issue # 135842. In absence of this - there need to be clear guidelines to module writers as to how to go about defining the shortcuts for their modules. Possible alternatives are: 1. Modules outside NetBeans should not define keyboard shortcuts. They may suggest the shortcuts in the module documentation. 2. There is a registry of keyboard shortcuts at NetBeans.org and the module writers have to register their shortcuts apriori. 3. The keyboard shortcut conflicts are detected by the Plugin manager and the user is made to resolve them right then and there. Let us see what theanuradha has to say.
It's certainly a bug. It would be great if the platform had a better system for resolving such conflicts, but currently it does not, so module authors must cooperate to avoid conflicts. Suggestion #2 (registry) makes some sense, though it is not needed for alpha AU modules since we already keep automated indexes of these things: http://deadlock.netbeans.org/hudson/job/javadoc-nbms/lastSuccessfulBuild/artifact/nbbuild/build/generated/layers.txt
I agree with jglick ,sandip if you want me to change my one?
@theanuradha Please go ahead and change your key bindings. However IMHO this is not the resolution of the bug. The registry that I am talking about is something that is managed by the HIE group so that the key bindings that anyone claims makes sense in the overall scheme of key bindings and in all the different profiles. The automated registry that Jesse is talking about "Suggestion #2 (registry) makes some sense, though it is not needed for alpha AU modules since we already keep automated indexes of these things: http://deadlock.netbeans.org/hudson/job/javadoc-nbms/lastSuccessfulBuild/artifact/nbbuild/build/generated/layers.txt" works only for modules that are built at NetBeans.org. What about modules built elsewhere?
I guess I need to do it myself. contrib #c912f86ed6d6