Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 115994 - Mobility use the same shortcut as form
Mobility use the same shortcut as form
Status: RESOLVED WONTFIX
Product: guibuilder
Classification: Unclassified
Component: Code
6.x
Sun All
: P4 (vote)
: 6.x
Assigned To: issues@guibuilder
issues@guibuilder
sp_review_61
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-19 13:45 UTC by Jana Maleckova
Modified: 2010-09-13 17:20 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jana Maleckova 2007-09-19 13:45:21 UTC
Product Version: NetBeans IDE Dev (Build 20070919053406) Java: 1.6.0_02; Java HotSpot(TM) Client VM 1.6.0_02-b05 System:
Windows XP version 5.1 running on x86; Cp1252; en_GB (nb)

Description:
============
in IDE installation with mobility, there is one shortcut used for two features - especially ctrl-shift-R. Mobility uses
it for action named "Re-Comment Preprocessor Bloks Action" and form module has assigned this shortcut for reload of form
class. According to rule that one shortcut should be assigned only for one action, this state is not desired.
Any suggestions ?
Comment 1 Adam Sotona 2007-10-05 12:11:40 UTC
The actions are similar on a different document types so I would recommend to keep it as is.
Does it cause any problem?
Comment 2 Adam Sotona 2007-10-08 09:48:19 UTC
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.
Comment 3 Jana Maleckova 2007-10-08 13:01:27 UTC
it causes real problem, if I install full IDE (together with mobility), ctrl-shift-R shortcut doesn't work for reload of
form.
Comment 4 Michel Graciano 2009-10-07 21:38:55 UTC
I don't know if it is still valid, but I am sure it could be addressed by NetFIX program if you agree.
Comment 5 Jan Stola 2009-10-08 10:45:26 UTC
> 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.
Comment 6 Michel Graciano 2009-10-08 13:31:46 UTC
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.
Comment 7 Jiri Kovalsky 2009-10-22 13:27:12 UTC
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
Comment 8 amelongo 2010-03-22 23:52:02 UTC
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.
Comment 9 Jiri Kovalsky 2010-03-23 08:41:52 UTC
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.
Comment 10 Tomas Pavek 2010-03-23 17:21:12 UTC
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...
Comment 11 Tomas Pavek 2010-03-23 17:24:30 UTC
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.)
Comment 12 Jiri Kovalsky 2010-03-24 16:59:52 UTC
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.
Comment 13 Michel Graciano 2010-03-24 17:14:29 UTC
I agree with Tomas argument. The patch at all is simple but the decisions should be taken by tool engineers.
Comment 14 gliesian 2010-04-23 20:08:47 UTC
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.
Comment 15 Adam Sotona 2010-09-13 14:54:33 UTC
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
Comment 16 Tomas Pavek 2010-09-13 17:20:18 UTC
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo