Bug 115994

The actions are similar on a different document types so I would recommend to keep it as is.
Does it cause any problem?

Closing as wont fix as we use this shortcut since nb 4.1 and there was not problem.
Please reopen if causing some real issue.

it causes real problem, if I install full IDE (together with mobility), ctrl-shift-R shortcut doesn't work for reload of
form.

I don't know if it is still valid, but I am sure it could be addressed by NetFIX program if you agree.

> I am sure it could be addressed by NetFIX program if you agree

I don't understand how you would like to fix it. The shortcuts probably still colide and neither form nor mobility want 
to change their shortcut. Even if form or mobility decide to change it, it is not clear what the new shortcut should 
be. There is a lot of shortcuts in the IDE and there is no simple way to find a non-coliding one.

I just lowered priority of this issue because it probably is not worth the effort to solve that. I guess that Reload 
Form action is not a frequently used action and I doubt that many people know and use its shortcut.

The idea is just define an new shortcut and change it. How to define it, is just part of the work the fixer should to do.
BTW, the use of Reload Form extensive since several Matisse problems should be fixed using it. Why? Several times the 
form editor doesn't reflect the current form state and force the reload solve it. I just don't file an issue yet because 
it is not so easy to reproduce it.

Michel, I think Honza agrees that this can be NetFIXed [1] provided it's not him looking for the suitable shortcut. ;-)
Adding appropriate keyword.

[1] http://wiki.netbeans.org/NetFIX

I'm willing to NetFix this issue, but WHO should tell me, or should I decide it on my own, the shortcut to be replaced with the current conflicting one? Let me know. Thanks.

Annabel, you can choose the shortcut yourself. Just be sure to verify that it does not conflict with any other shortcut! So, don't wait for anybody else.

I don't want to look ungrateful but I think this is not a suitable issue for NETFIX. It is only about deciding on which action the shortcuct needs to be changed (GUI builder or mobility) and how. That needs to be agreed by module owners. Also introducing a new shortcut, making sure it is reasonable, should be approved by HIE. The patch itself is a trivial one-liner, but still many people need to be involved. We welcome any opinion or advice, indeed. But there is little for an external contributor to work on standalone.

It would be a different case if someone wanted to study the action system and come with a solution that would allow to have the shortcuts context sensitive instead of global, and so allow to live with the existing shortcuts unchanged. That would be IMHO the right solution for this problem. There are many different actions applicable in specific context that never meet together, why could they not have same shortcut? But that would be pretty non-trivial task...

Now to the problem itself: we need to change the shortcut either for the GUI builder's Reload Form action, or "Re-Comment Preprocessor Bloks Action" from mobility. When they both meet in one IDE now, the shortcut does not work.

I'd suggest to change it for the Re-Comment action for couple of reasons:
* Reload Form is likely used much more frequently.
* The Reload Form action used to have Ctrl+R shortcut which started to collide with rename action when refactoring was introduced, so was changed to Ctrl+Shift+R. Changing it again to some obscure combination will screw it up definitely.
* The Re-Comment action as an editor action could follow the overall changes done for NB 6.0 when commenting a block of code was changed to Ctrl+/. So maybe Ctrl+Shift+/ would be a reasonable shortcut for this action. I don't see such a reasonable shortcut for Reload Form.

If there is no consensus on which action the shortcut should be changed, I'd prefer to leave it as it is. The problem (shortcut not working) appears only if Java SE and Mobility are active in the same IDE - which thanks to the Feature on Demand is not that frequent case. (E.g. a user of full IDE who never uses mobility will have no problems in GUI builder with the shortcut.)

OK, I take your argument Tomasi. The potential simplicity of this patch in case only a shortcut is changed was the reason why Michel nominated this bug to the NetFIX pool. Removing the keyword.

I agree with Tomas argument. The patch at all is simple but the decisions should be taken by tool engineers.

I personally don't see shortcut conflicts ever going away with a 'shortcut registry'...  and context sensitive shortcuts will only cause confusion, IMHO.... unless the functionality of the shared shortcut is closely related.

Take a look at this issue I opened, suggesting the creation of an shortcut registry: http://netbeans.org/bugzilla/show_bug.cgi?id=182619.  

Thanks.

From Mobility owner perspective:
- at the time the "Re-Comment Preprocessor Blocks Action" shortcut was designed, there was no collision with other parts of NetBeans
- all proposed alternatives for "Re-Comment Preprocessor Blocks Action" are already used
- Form editor made a mistake and did not check for collisions when changed their "Reload" action shortcut
- the broken functionality is now also on Form editor side
- there is no general conclusion to make the actions context-sensitive

...so I can hardly help and re-assiging to Form

Adam is right that mobility did not caused the situation, but does not want to accept that mobility is the place where this can be easily fixed (e.g. by using Ctrl+Shift+/ instead), unlike the GUI builder as I tried to explain. I'm afraid this issue is WONTFIX then.