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 47510 - [40cat] Request selection-sensitive variants of standard main-project-sensitive actions
Summary: [40cat] Request selection-sensitive variants of standard main-project-sensiti...
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Projects UI (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: Petr Hrebejk
Keywords: RELNOTE
: 47762 (view as bug list)
Depends on:
Blocks: 41535
  Show dependency tree
Reported: 2004-08-19 18:57 UTC by shemnon
Modified: 2006-03-24 10:28 UTC (History)
3 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description shemnon 2004-08-19 18:57:44 UTC
[ BUILD # : 200408121535 ]
[ JDK VERSION : J2SE 1.4.2_04 ]

The run->run other menu appears to be full of entirely bogus data.  (test project, separator, run file, debug file,  test file, debug test for file).

This may be related to the fact that I only have freeform ant projects opened up.
Comment 1 Jesse Glick 2004-08-19 20:07:47 UTC
All of the above can be bound to targets in a freeform project if you
wish to do so. (They are bound for standard Java projects.)

"Test Project" is easiest - just need a test target (supported
directly in property dialog for a freeform project). The others are
more subtle because you need to pass the file selection as an Ant
property; there is no GUI support for configuring this, but it can be
done in the project.xml by editing as text.
Comment 2 shemnon 2004-08-19 20:32:09 UTC
Well, what is also missing is "run project" which corresponds to the
defined run task.  So run project and test project would be
sufficient, and if run file and test file can be implemented in the
peoject.xml without too much heavy lifting that would be good too,
otherwise I'de almost rather see them gone then to have no way to
enable them for a freeform project.
Comment 3 Jesse Glick 2004-08-19 20:40:53 UTC
Run -> Run Main Project is enabled for a freeform project if that
project is selected as the main project and it has a binding for Run.
Test Project is sensitive to the selection (in editor, tree views,
etc.) rather than to the main project, under the assumption that you
are likely to run tests for library subprojects even if you are going
to the main project to run an app.
Comment 4 shemnon 2004-08-19 21:15:43 UTC
That is the essense of this bug then.  I want to be able to run
another freeform project whether or not it is the main project.  

I may open and work on some other side projet that is not a proper
library or even I may have multiple main classes in a project that I
can bring in from a corprate SCM structure.
Comment 5 Jesse Glick 2004-08-20 15:34:31 UTC
There is a global action Run Main Project which runs the main project.
There are context menus on projects which support Run which allow you
to run them whether or not they are the main project. This is all as
designed. You can also bind Run File in freeform projects to be able
to run individual classes (or any files for that matter - need not
even be *.java) according to the current selection.
Comment 6 shemnon 2004-08-20 15:53:59 UTC
What you are missing is the usability aspect of this bug.  

How on earth do I do these things whout a mouse?  Having to re-assign 
each project I load to the main project and then run main project is 
way too manu steps, espcially sine the precident is set 
with "generate javadocs for <project>" can focus on a per project 
basis.  What the user needs is that any task that has a main project 
vairnet also has a focused project vairent, simple usability and 

Since it appears to me that projects group is digging in to resist 
fixing this usability issue I am moving it to the UI group to see if 
there is anyone who is concerned about usability and whon't hide 
behind "it wasn't designed that way."
Comment 7 Jesse Glick 2004-08-20 17:53:17 UTC
Totally wrong component, that is not helpful. (Anyway the relevant
person on the "UI group" is part of the "projects group".) I'm not
ignoring the usability aspect at all - the current system was decided
upon after enumerating a lot of use cases, trying to estimate the
relative frequency of certain actions in different scenarios, and
choosing a set of menu items that would capture the most commonly
needed actions without bloating to include too much. The result may be
right or wrong - it is certainly a compromise which will appear more
or less reasonable to different people - but it was not arbitrary.

There are several ways to access actions such as Run on non-main
projects without a mouse. One is to set the main project using Alt-F M
<<move up/down>>, then run the action (best if you are likely to run
the same project a couple more times). Or, assuming you have a file
from the project open, you can use Ctrl-1, then left arrow repeated
until you get to the project node, then S-F10 and select the action.
Not as fast as a KB shortcut, of course.

Related to this request is the handling of actions specific to a
single freeform project (filed separately), which would be present in
the main menu only via a dynamic submenu (tricky on Mac OS X).

Leaving to Jano to consider future changes.

BTW it would be straightforward to create project-sensitive variants
of these actions and install them in the Actions pool without adding
them by default to the main menu or making KB bindings for them; would
permit users with a definite preference for the project-sensitive
versions to use those instead or in addition to the main project
versions. This is I think would be harmless to do for 4.0.
Comment 8 shemnon 2004-08-20 18:01:01 UTC
Thank you for addressing this in the future.  I woulmd prefer it in 
4.0 but I realize that schedule and delivery may make that 

I feel that is a more appropriate resolution than "invalid" or "won't 
fix."  Those resolutions make the bug sumitter feel like their input 
is being flatly ignored.
Comment 9 Jesse Glick 2004-08-20 19:20:59 UTC
No one's bug reports or RFEs are flatly ignored (assuming the
description is complete and in somehow legible English).

However major UI changes probably can't be made this late in the 4.0
dev cycle due to the QA and docs burden. These are usually marked
"future" (could be "E" ~ 4.1).

Other UI changes (often ones that have already been considered and
rejected) have to be declined because they conflict with other goals -
unless there is a preponderance of evidence from users that the other
goals are secondary in importance. These are usually marked "WONTFIX".

Some others would be desirable but there is no known way to implement
them (including all the border cases) without a substantial increase
in code complexity, which could threaten the IDE's stability as well
as take a lot of time to write and test; these could be "future" or

"INVALID" is generally used if the assignee believes the reporter did
not provide enough information to make him/herself understood, or was
missing some piece of information which if explained would invalidate
the bug or request. (Though getting repeated bug reports based on the
same missing information or misinterpretation usually points to a
basic documentation or UI problem.)
Comment 10 Jesse Glick 2004-08-24 17:34:31 UTC
*** Issue 47762 has been marked as a duplicate of this issue. ***
Comment 11 Petr Hrebejk 2004-08-30 12:16:05 UTC
The actions are there. User can add them to menu or toolbar and/or
assign a shortcut to them.

Checking in
new revision: 1.14; previous revision: 1.13
Processing log script arguments...
More commits to come...
RCS file:
Checking in
 <--  buildCurrentProject.gif
initial revision: 1.1
RCS file:
Checking in
 <--  buildCurrentProject24.gif
initial revision: 1.1
Checking in
 <--  layer.xml
new revision: 1.38; previous revision: 1.37
RCS file:
Checking in
 <--  rebuildCurrentProject.gif
initial revision: 1.1
RCS file:
Checking in
 <--  rebuildCurrentProject24.gif
initial revision: 1.1
RCS file:
Checking in
 <--  runCurrentProject.gif
initial revision: 1.1
RCS file:
Checking in
 <--  runCurrentProject24.gif
initial revision: 1.1
Comment 12 Milan Kubec 2004-09-01 11:01:13 UTC
Verified in custom 20040901. BTW great feature, developing is easier.
Why those actions cannot be on the main window toolbar by deafult? It
should be at least documented. Adding Patrick on cc.
Comment 13 Patrick Keegan 2004-09-01 11:18:04 UTC
John, this might make for a useful topic or tip.