Community
Participate
Working Groups
That is, if I'm editing class Foo (which has a main method), the "Run >" submenu of the Run pull-down has an item called "Java Application". If I select it and launch Foo, an item called "Foo (application)" will appear in the Run History submenu. As these two items do the same thing, they should have the same name.
Adding Wayne as CC for comment. There are definitely some technical issues here, but I'm wondering if there are similar requirements for WS* tooling.
From the bug description: "As these two items do the same thing, they should have the same name." This actually isn't true. "Run As > Java Application" and "Run (history) > Foo" are distinct actions. The "Run As" action looks for launch configurations that apply to the selected file. If more than one is found, the user is asked which config they'd like to use. If no configs are found, one is created. If one config is found, that config is used. The Run History explicitly asks to run a particular configuration. Unless I'm misunderstanding the original request, it is invalid.
You are correct in that the run history and the "Run As > Java Application" do different things. However, I think it is still a valid request to have a better description. For example, when a type of compilation unit is selected, we could show the name of the main type that would be launched, like "Run > HelloWorld". This also needs investigation, as the naming when containers (projects/packages) are selected are more ambiguous (i.e. "Run > MyProject"). In this case, we would still need to indicate what you want to search for - a main type, an applet, ... etc.
I remember seeing a request along those lines; I thought we had another bug report for it. I don't think I understand the specific example you gave, though. "HelloWorld" is a better description of running as Java than "Java Application"? Run As > HelloWorld, HelloWorld, or HelloWorld? :-P
:-) The example I had in mind was when you select a type "HelloWorld" that has a main method, the menu item would read "Run > HelloWorld | Run...". There would only be two choices and it would state explicitly what was going to be run - i.e. the main type. If it was an applet with a main method, then we might do something like "Run > HelloWorld (Applet) | HelloWorld (Java Application) | Run...".
I think the user's context is defined by what they selected. If they select a type FooBarApplicationEntryPoint, I don't think we need to repeat that information in the menu items. If we followed that convention everywhere, though, the context menu would be a mess. Right click on Java type FooBarApplicationEntryPoint: Open Type Hierarchy of FooBarApplicationEntryPoint Copy FooBarApplicationEntryPoint Paste My copied text from some other document... Delete FooBarApplicationEntryPoint Source > Format FooBarApplicationEntryPoint Sort Members of FooBarApplicationEntryPoint etc. (FooBarApplicationEntryPoint) etc. (FooBarApplicationEntryPoint)
To a new user, its not clear to which file or project the "Run >" submenu of the top-level, pull-down "Run" menu refers. There's no clear connection between it and the file that happens to be on top in the editor (or highlighted in the project browser). To make this connection explicit, the "Run >" submenu should be renamed "Run Foo.java As >" or "Run MyProject As >". Otherwise, a beginner will think that its contents change or disappear randomly. I'm not, of course, suggesting that the items of a context menu that appear when the user right-clicks on a file should repeat that file's name.
(OK, so the clarification is that the top level RUN menus are confusing, not the context menu in a view).
This argument applies to every button and menu action in the workbench. Eclipse users simply have to learn that actions apply to the selected item in the selected view or to the active editor.
Jared: I agree completely; this is an important thing for Eclipse users to understand. But why not make it easier for them by providing the filename? Start with the Run and Debug submenus, as they're the most important. This seems like a relatively easy fix (correct me if I'm wrong) that would make the menu clearer for both new and experienced users. Why not do it?
Overall, I would say that your idea is fine for people who write Java main types. But I don't think it works for our platform. My original objection was because appending the name to every action looks extremely ugly. It clutters the menu items with redundant text which totally waters down the *real* information (Java, C, Applet, etc.) Run As > HelloWorld.java (C/C++ Application) HelloWorld.java (Eclipse Application) HelloWorld.java (Java Applet) HelloWorld.java (Java Application) Your suggestion in comment #7 is better, but it's still got a similar presentation problem. File names can be long and putting them in the middle of the menu makes the menu huge; also, having a dynamic word in the middle of our action label makes it harder to pop up the menu and find "Run As" because the action's name is different every time. Run LaunchConfigurationProjectMainTypeChange.java As > C/C++ Application Eclipse Application Java Applet Java Application Also, it turns out that saying "Run StringVariablePreferencePage.java As" isn't always accurate. The "Eclipse Application" is an example of this. It's context sensitive, but it doesn't actually care about which file is selected. The problem of "What does this action apply to?" is a general problem in the workbench. I'd like to see the problem solved, but appending the name of the selection to every action simply isn't going to be the solution. If we were making a video game, I'd say that it'd be cool if the applicable part (view or editor) would glow softly when you highlighted an action. :-)
Sure, class names can be that long, but they usually aren't. I doubt you'll find many that would make the menu wider than the "Add Java Exception Breakpoint" item does. And if the class name is as long as your example, I'd argue that the menu width highlights an awkwardly-named class, not a badly-designed menu. The increased menu clarity provided by the class name outweights the slight delay (if there is one) of locating the menu item. Anyone who's running a class repeatedly probably uses the keyboard shortcuts anyway. I'm not suggesting that you include the filename in many places; only the "Run As" and "Debug As" submenus of the top-level "Run" pulldown menu. This menu is confusing and very important for beginners. Other menus which include context-sensitive menu items are not as crucial or confusing. I'm only asking for changes to two menu items. What do you mean by "people who write Java main types"? My suggestion applies to anyone who wants to run a Java application or applet, which seems to cover most of the people who use the Run menu. What does the "Eclipse Application" item mean? I only see it when I have a view selected, and if I launch it, it brings up a Resource window with "Overview", "Tutorials", "Samples", etc. in it. To summarize, I'm asking for a specific change to two menu items. This change would greatly clarify a commonly-used menu and go a long way towards helping beginners cope with Eclipse's generality. Will you please make this simple fix?
"And if the class name is as long as your example, I'd argue that the menu width highlights an awkwardly-named class, not a badly-designed menu." Hey now, let's not get personal. :-P FYI, "Eclipse Application" is for Eclipse plug-in development. It's an example of a kind of launch shortcut that cares about the selection but doesn't actually "launch" the selection. It illustrates the fact that it doesn't always make sense to say "Run <file> As".
We are in the process of investigating how to improve the Eclipse launch story (from launch configs to run menus, etc.) and I think it best to not make this change just yet until we have a better picture of the higher-level design changes that may happen.
Glad to hear that Wayne. What kinds of changes are you planning? Is there any way I can follow your discussions? Nothing personal, Jared. :) I know classes sometimes need long names, but we always grimace when we give them one, don't we?
See comments on bug 74480. This bug is a symptom of the same underlying problem: i.e. simpler launching. Rather than address the symptom, we are going to mark this bug as a dup of 74480, and consider it in conjunction with other options for simplifying the launch experience. *** This bug has been marked as a duplicate of 74480 ***
