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.

Bug 21249 - Shortcuts to target should be project specific
Summary: Shortcuts to target should be project specific
Alias: None
Product: projects
Classification: Unclassified
Component: Ant (show other bugs)
Version: 3.x
Hardware: All All
: P4 blocker (vote)
Assignee: Jesse Glick
Keywords: UI
Depends on: 26338
  Show dependency tree
Reported: 2002-03-06 15:12 UTC by Milan Kubec
Modified: 2006-11-15 00:15 UTC (History)
0 users

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Milan Kubec 2002-03-06 15:12:16 UTC
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.
Comment 1 Jesse Glick 2002-03-06 16:25:31 UTC
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.
Comment 2 Jan Pokorsky 2002-07-31 19:28:17 UTC
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.
Comment 3 Jesse Glick 2003-12-19 15:45:28 UTC
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.
Comment 4 Jesse Glick 2004-05-05 16:19:49 UTC
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.
Comment 5 Jesse Glick 2004-06-09 02:16:24 UTC
Freeform project type is a better solution to the user need, I think.
Comment 6 Jesse Glick 2005-06-03 18:00:40 UTC
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).
Comment 7 Marian Mirilovic 2005-12-20 16:05:07 UTC
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.
Comment 8 Jesse Glick 2006-01-07 21:26:24 UTC
Actually know how to implement. Not very hard.
Comment 9 Jesse Glick 2006-01-07 21:28:11 UTC
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.
Comment 10 Jesse Glick 2006-01-09 21:11:28 UTC
committed   * Up-To-Date  1.28        ant/nbproject/project.xml
committed   * Up-To-Date  1.14       
committed   * Up-To-Date  1.30       
committed   * Up-To-Date  1.10       
committed   * Up-To-Date  1.273       ide/golden/deps.txt