From the FFJ user test: The user clicks the Execute toolbar button with
non-executable class in focus in the editor, but executable class selected in
the explorer (but not in focus). However, it is not clear to the user that
the executable class in the explorer is not "in focus" and they expect it to
The user is then confused by the error that appears in the output window in
the Running workspace when the IDE attempts to execute the non-executable class
The Execute command/toolbar button should be disabled if the class in focus
(whether in the editor or in the explorer window) is not executable. Also,
the selected node in the explorer should be altered (perhaps gray) when the
explorer is not in focus.
This bug is enhacement. Core team has not responsibility to this bug. Disabling
execution command is not the best idea. Excution action for example do at first
"Executability" is not straightforward; it means different things for ordinary
Java classes, for classes deployed on an application server etc. The user can
specify its own execution method that even don't look for void main(String) so
executability detection can't be hardcoded into IDE's base.
i think what the concern is here is that execute is enabled on classes when
they will produce an error. we should do some basic checking that if there
isn't any user or other-module defined execution setting on the class and there
isn't a main method then execute should not be an enabled action.
Chris is correct. But I also believe that somehow graying or hiding the
selection in the explorer (since it's currently not relevant when you're in
another top level window) would make it clearer which object is in focus.
I hate to said that, but I don't think that source parsing is reliable enough so
action enabling should depend on it. Consider a source with errors; user wants
to run it so he triggers Run action, the source will be compiled and the errors
will be shown to the user. The parser might not even see main() method in source
that has some serious errors - so if the action is available depending on
presence/absence of run() (in the default case, of course), the user won't be
able to trigger the action and will need to explicitly invoke compilation.
Is that acceptable ?
No response; closing as WONTFIX. I think that Run action should be available
at all times on all nodes that supports an Executor. It is Executor's task to
print out some reasonable message.
I can live with not disabling Execute. It would, however, be nice for the IDE
to warn the user that she is about to do something that is a known error (i.e.,
execute something without a main procedure). Otherwise, it confuses the user
and makes us look a bit silly!
So here's my suggestion. If the user tries to execute something without a main
procedure (and that has no other means of execution), we pop up a warning dialog
"Executing <filename> will fail, since it does not have a main procedure.
Would you rather Build it instead?"
[Build] [Execute] [Cancel]
I imagine this should also have a checkbox that says, "Don't show this message
After some more thinking:
If the file is not built (it has some errors or something), the Execute action
will notice that and will try to compile the file - resulting in errors.
If the file is up-to-date (for some reason), it can be reliably scanned and the
executor can detect that something is wrong.
The point is, that only the executor can detect this situation, not the java
(or whatever other) object itself, since it can be configured to do something
completely custom by the user.
Nice approach would be that used in filesystem-object node communication: give
the executor a chance to affect the node's icon (or overall presentation).
If possible, compiler should be given the same option.
What about moving this discussion to nbdev@/nbui@ ?
Resolved for 3.3.x or earlier, no new info since then -> closing.
Resolved for 3.4.x or earlier, no new info since then -> closing.
Reorganization of java component