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.
Shortcuts to target created in one project can have no sense in another project, thus IMO these shortcuts should be project specific (stored in project layer, similar as project settings - if it's the same case, I don't know). It could be configurable during creating the shortcut.
I guess there are two cases to consider. 1. The user is adding a shortcut to the project tab. In this case obviously it is already project-specific. 2. The user is adding a menu item, toolbar button, or keyboard shortcut. In such cases the user can already make the addition project-specific manually, using the Options dialog. However I agree that a default of project-specific is more sensible. For #2, there are two possible problems: a. Currently menu items / toolbar buttons / keyboard shortcuts are never normally made project-specific. It can be done of course, but it is unconventional. For example, modifications made via the Options dialog's Look & Feel nodes are by default applied globally. So if you were to add a project-specific menu item, then rearrange the menu order in the Options dialog, the rearrangement would take effect globally; in other projects, the menu would be rearranged but that menu item would be missing. Not necessarily harmful, but potentially confusing for a user. b. As far as I know there is no support from the APIs for making a new file project-specific. Jan/Vita, please correct me if I am wrong, but as I understand it: - The attribute SystemFileSystem.layer=project on a file means that modifications to it will be stored in the project directory. It is designed for use from XML layers. - This attribute is not supported by the APIs; it is advisory and so may stop working in a future release. - The attribute is interpreted only when a modification is made to the file. The shortcut wizard creates a new file. It could then set the attribute on the file. But it would be too late; the file (Ant *.xml) would already exist in the userdir as a global setting. Subsequent modifications should likely be stored in the project directory. However deleting the file from the user directory is not then possible from the APIs: since it is now project-specific, it would rather leave the file in the user directory and store a mask in the project directory indicating that it be not visible in this project (the exact opposite of what you want). I can imagine some hacky code that would make it work, but it would not be very safe - it could break completely with minor changes in the core infrastructure. Nor do we want to add an API to do such a thing, I think, because since project support is being rewritten anyway we do not want to commit to the current design. So leaving open but do not expect it to be implementable soon. Can be reevaluated later.
ad 2b) the attribute SystemFileSystem.layer=project can be specified also on a parent folder thus all newly created files are considered as project-specific. Of cource that does not help if you want to alternate creating of project/session specific files. In scope of the new projects implementation there are prepared APIs solving project specific settings.
No plans to do anything for 3.6. For promo-D or later, might want to do something along these lines, but too early to say what exactly it should be. May not even be necessary at that time given other changes.
No clear UI behavior in new project system. Could make menu and toolbar items visible or not depending on open projects, if issue #26338 were implemented. Possibly without that (except for keyboard shortcuts), TBD. But whether sudden changes to toolbars etc. when projects are opened and closed would really be desirable is TBD.
Freeform project type is a better solution to the user need, I think.
Of related interest: issue #58588 (tasks in project context menu), issue #50111 (unfiled subtopic - GUI to add new custom project action with per-project bindings).
This issue was solved long time ago. Because nobody has reopened it neither added comments, we are verifying/closing it now. If you are still able to reproduce the problem, please reopen. Thanks in advance.
Actually know how to implement. Not very hard.
If the shortcut file has exactly one <ant> task, which uses antfile="..." or dir="..." to specify a build script to delegate to, and that build script is owned by a project, then the menu item or toolbar button will be visible (or a keyboard shortcut active) if and only if the project is currently open. Otherwise the shortcut is always active.
committed * Up-To-Date 1.28 ant/nbproject/project.xml committed * Up-To-Date 1.14 ant/src/org/apache/tools/ant/module/loader/AntActionInstance.java committed * Up-To-Date 1.30 apisupport/project/test/unit/src/org/netbeans/modules/apisupport/project/queries/ClassPathProviderImplTest.java committed * Up-To-Date 1.10 apisupport/project/test/unit/src/org/netbeans/modules/apisupport/project/queries/SubprojectProviderImplTest.java committed * Up-To-Date 1.273 ide/golden/deps.txt