Bugzilla – Full Text Bug Listing
| Summary: | [launching] Simplify the launch experience for less technical users of Eclipse | ||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Wayne Ho <who> | ||||||||||||||||||||||||||||||||||||||
| Component: | Debug | Assignee: | Michael Rennie <Michael_Rennie> | ||||||||||||||||||||||||||||||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||||||||||||||||||||||||||||||
| Severity: | enhancement | ||||||||||||||||||||||||||||||||||||||||
| Priority: | P3 | CC: | bpasero, chanskw, daniel_megert, darin.eclipse, dkhodges, eclipse, joerg, ken.ryall, lding, martin.gutschelhofer, n.a.edgar, nils, recoskie, uwe.st, web, wmitsuda | ||||||||||||||||||||||||||||||||||||||
| Version: | 3.0 | ||||||||||||||||||||||||||||||||||||||||
| Target Milestone: | 3.3 | ||||||||||||||||||||||||||||||||||||||||
| Hardware: | All | ||||||||||||||||||||||||||||||||||||||||
| OS: | All | ||||||||||||||||||||||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||||||||||||||||||||||
| Bug Depends on: | 170142, 170144, 170145, 175180, 175332, 176430, 176440, 176841, 177132 | ||||||||||||||||||||||||||||||||||||||||
| Bug Blocks: | 154107, 170111, 423767 | ||||||||||||||||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||
|
Description
Wayne Ho
Marking as 3.1. Currently, we are investigating ways to improve simplify the user experience. Discussing the launch usability issues between the debug team and Wayne, we have recognized the following goals: * To make launching simple for the simple case * To provide power and flexibility for advanced launching options And we noted: * The current launch dialog provides powerful editing/management features of launch configurations that advanced users are comfortable with, and do not want to lose. * The dialog can be viewed as more of a "configuration management" tool than a launching tool (although, it can also be use for launching) We believe that we should seperate the problems simple launching and providing advanced/powerful launch configuration management. The launch dialog provides configuartion management, and context lanuching provides simpler launching. Both features can be improved. I will open new bugs to address polish items in the lanuch dialog to improve the configuration management experience. I will leave this problem report open as a collecting grounds for simplifying the launch experience. It is not clear if simplyfying the launch experience is something that can be acheieved in the 3.1 time frame, so I will mark the bug report as later for now. We can open specific enhancements for 3.1, time allowing. Some initial ideads are: * Reducing the number of launch shortcuts that appear in the run/debug context menu. For example, when a plug-in project is selected there are currently 5 options: Eclipse Application, Java Applet, Java Application, JUnit Plug-in Test, JUnit Test. Really, there should only be one option: Eclipse Application. * Renaming the "Run... " options to indicate they are for configuration management rather than launching. New users often choose these options only to be confronted by a complex dialog, and they don't know how to proceed. * Reworking the "Run..." options to provide a simpler "launch" experience (perhaps open a wizard to guide the user through launching the selection). This would be new function added on top of the existing function. *** Bug 77784 has been marked as a duplicate of this bug. *** *** Bug 133352 has been marked as a duplicate of this bug. *** re-opening for 3.3 We would like the make the run/debug/... buttons do the right thing based on the user's context. If we cannot determine an appropriate way to launch based on the user's context, we should prompt the user with some simpler options to help them launch, rather than open the launch dialog. The following can be used to build a user's "launch context": * Resource being edited (derived from active editor, or selection in navigator) * Project associated with that resource This provides us with the following: * Project natures associated with that project * Configurations associated with the resource (or project, if none) * Lanuch shortcuts applicable to the resource (or project, if none) Scenario (1) ----------- The first time a user attempts a launch, we could provide them with a list of applicable launch shortcuts, based on their context. For example, let's say they have a .java file selected in a plug-in project. The .java has no main method. In this case, the context looks like: * Resource: SomeClass.java * Project: some.plug.in * Natures: java, pde * associted configurations with resource: none * associted configurations with project: none * associated shortcuts with resource: none * associated shortcuts with project: Eclipse Application, Equinox, Java Applet, Java Application Since there is currently no "context history" to follow, we would prompt the user with a wizard asking what they would like to "debug" (or run - which ever button they press). The list would be populated with the list of applicable shortcuts - in this case: Eclipse Application, Equinox, Java Application, and Java Applet. NOTE: Currnetly launch shortcuts only have names (for the menu), and no descriptions. Ideally, we could have launch shortcut extensions provide small descriptions, to be displayed in the wizard. The user then selects "Eclipse Application" (they are doing plug-in development), and press "Debug". Control is then handed to the shortcut to launch a workbench. We then make a mapping of launch context to the shortcut that was used. We use this information on subsequent launches. NOTE: the wizard could be enhanced to allow launch shortcuts to specify wizard pages to use - so the user could press "Next" in addition to "Debug". Scenario (2) ----------- The next time a user attempts a launch any .java file (with no main) in a plug-in project, we would see that the context (project natures, associated configs, and assocaited shortcuts) mapped to the "Eclipse Application" being used. We pass control to the Eclipse application shortcut. Scenario (3) ------------ A user selects a .java in a plug-in project that has a main. This time there are shortcuts applicable to the resource (Java Application, possibly SWT and JUnit). If there is only one applicable choice, we pass control to the shortcut, else we open the wizard. Notes: ------ As the context is more specialized, we provide different launch behavior. This time a .java file was chosen in a plug-in project, but the set of applicable launch shortcuts has changed on the resource itself. By mapping contexts to "what the user did", we should be able to do the right thing most of the time. In the case that they need to do something special, they can still open the launch dialog. This would require no new API - it would be all optional (shortcut descriptions and optional wizard). As well, it should have minimal impact on what the user expects the run/debug buttons to do. Currently, the run/debug buttons launch the last thing that was launched. This behavior should remain consistent, based on user context. Created attachment 53335 [details]
prototype for experimentation
The patch creates contexts based on the selected resource. It caches the launch shortcut used for the cross product of (resoruce x applicable shortcuts x project natures). It also caches the shortcut for the more general case of (applicable shortcuts x project natures). This way when a similar resource is chosen in a similar context, the shortcut is reused. However, it also allows specialization at the resource level.
The current patch is rough in terms of prompting dialog, does not have a wizard, and does not persist shortcut info across workbench invocations.
Can I suggest an alternate approach? Rather than launching the current resource and asking the user to select a launch shortcut when they attempt a launch, a default launch configuration should be associated with a project when it's created. That is, a user should be asked to create a project containing either a Java application or a Java applet (or one of the other available options). These could be two options in the "New Project" dialog or selected via an option in the "New Java Project" wizard. Each newly created Java project (I'm not familiar enough with the other project types to know if this applies) should have a default main class automatically generated (with either a name matching that of the project or one entered by the user). This combination of launch shortcut and main class would be saved as the default launch configuration and could be edited or replaced with a new configuration in the existing launch configuration dialog. Besides being consistent with other IDEs (e.g. Visual Studio and Xcode), this approach has the advantage of fitting most users' mindsets; that is, users usually know if they want a Java applet or application when creating a project, but when they launch their project they are more concerned with trying out their code than in selecting a launch shortcut. Additionally, because a program typically consists of many co-dependent classes, users usually think about launching a project, not an individual class; thus, they may be confused when the launch behavior changes based on the active file. In short, associating a default launch configuration with newly created projects would greatly simplify Eclipse's launching experience. I think the ability to have a default launch configruation (or kind of launch configuration) for a project is a good idea. It should be optional, and work in addition to the already proposed support. Since some projects have many executables (for example, a project of many tests), we cannot limit a project to have only one launchable entity. I've updated the following document to capture current thouhgs/proposals on launch enhancements: http://dev.eclipse.org/viewcvs/index.cgi/*checkout*/platform-debug-home/r3_3/docs/Context-launching.htm?rev=HEAD&content-type=text/html I updated the aforementioned document with some thoughts about context sensitive filtering for the launch dialog and property pages. *** Bug 165103 has been marked as a duplicate of this bug. *** We would also like to support sharing of default launch settings with a team in a respository. We will investigate the use of project scope preference settings to do this similar to how Java compiler options are stored with a project. We can use preferences to store a mapping of resources to associated default configurations. When a user shares a configuration that is default, an enty is added to the project scope preferences with that mapping. Thus, the user work flow to share default settings is to simply share the configuration. If it is marked as default, that will be stored with the project setttings. Created attachment 54442 [details]
patch
This patch experiments with an API for setting/getting default configs for resources. A property page displays configurations assocaited with resources and allows a single configuration to marked as the default configuration for that resource.
In the case that a config is shared (i.e. a resource in the workspace), the default launch settings for that project are stored as project prefereces so that default settings can be shared with a team. There is a limitation that a shared default config must reside in the same project it is a default configuration for.
Created attachment 54503 [details]
Patch
This patch adds to the default launch settings for projects experiment. Having the ability to see the configurations relevant to a project on the property page seems useful. However, having the ability to create/delete/modify configruations from this page is problematic, as the page has a "cancel" button.
Supporting cancel becomes problematic with the current launch configuration edit lifecycle infrastructure as the launch dialog used to edit configurations commits changes when the user presses "apply" or "OK". The edit dialog is opened from the property page. The patch experiements with supporting cancel by working only on "working copies" of the launch configruations, but this causes problems for the launch dialog for things such as name validation (becuase the dialog only knows about "existing" configurations, not the ones being edited but not yet committed by the property page).
Created attachment 55420 [details]
updated patch
Updates to reflect the current state of HEAD
Released API to debug core for get/set default configuration and nested working copies. See new API in ILaunchManager and ILaunchConfigurationWorkingCopy. Created attachment 56341 [details]
patch
Updated patch to contain just properties page (work in progress), reflecting new API released to debug.core
released extension point addition for launch shortcuts to map them to a configuration type, updated the test suite and updated our launch shortcuts. see LaunchShortcutExtension, LaunchConfigurationManager, and the launchShortcuts extension point released get/set default launch shortcut for a given resource, as well as updated the test suite with junit tests for it. see LaunchConfigurationManager, LaunchShortcutExtension and LaunchShortcutTests Added two internal methods for generating unique configuration names given a set of reserved names. Facilitates working with 'virtual' configurations in the default config property page. Since configs created in that scope do not technically exist yet, we need to make the launch manager and launch dialog aware of their names when creating new ones (they are reserved names). see doc on methods LaunchManager#generateUniqueLaunchConfigurationNameFrom(String, Set) and LaunchConfigurationsDialog#generateName(String, Set) Added in checks to validate launch configuration names that are 'virtual' i.e. those that are being worked on in the context of a the properties page and are not yet committed (formally saved with notification). Created attachment 56426 [details]
Patch for property page
Improved property page with toolbar actions.
Created attachment 56666 [details]
work in progress
This patch refines and adds the following:
1. The properties page is polished and working, also brought more in line with other properties pages (button-wise)
2. The launch dialog is updated allowing the apply and revert buttons to work correctly with nested working copies
3. An experimental pref page is included for context launching, which allows it to be turned on/off
4. Object contribution items have appropriate enablements to respond to context launching in use
5. Launching toolbar actions are responsive to context launching
6. Polished ILaunchConfiguraitonWorkingCopy API in terms of nested working copies
7. Polished getting and setting of default launch configurations to addres an illegal state exception
8. Added IResource context filtering to types of launch configurations available to create from the properties dialog
Found the following outrstanding issues so far with the above:
1. IResource context filtering does not quite produce what it should, this is in part due to the fact that currently we use the enablements of applicable launch shortcuts to derive the launch config types to include, but in the case of no mapped type we in effect end up adding all of the types anyway (or leaving out some that could apply)
2. The run methods of the new context launching actions are not yet implemented
3. Menu items in the 'Run' menu are not yet responsive to context launching, possibly look at beefing up the activity filter to handle visibility of those ones
Created attachment 56675 [details]
work in progress 2
adds some junit test revisions to LaunchConfigurationTests
Created attachment 56736 [details]
work in progress 3
This patch improves over the others with:
1. robust filtering of applicable types when creating launch configs from the properties page
2. property tester for properties page to not show it when context launching is disabled
3. Open launch dialog action added to toolbar when context launching is enabled
4. can launch default configurations for resources
Most immediate items remaining:
1. if a default config has not been assigned you get the launch dialog right away, this needs to be improved to pear-down choices and only show that monster if absolutly necessary
2. the run menu does not respond to the enabled state of context launching
Filtering of types is done via launch shortcut expressions. To make full use of this, additional attributes are required for providers of launch shortcuts. More specifically the id of the configuration type a shortcut creates should be added to the shortcut contribution. This patch includes the patches for all of the platform launch shortcuts (PDE, Junit, JUnit plugin, Ant, Equinox).
Bugs have been filed with PDE (170142), JUnit (170144) and Ant (170145) to get the missing attribute added.
Created attachment 56804 [details]
work in progress
This patch includes all others to date and the following:
1. A context runner to be reused by multiple kinds of actions
2. A launch shortcut selection dialog, with check button to set as default method to launch a resource
3. Improved launching flow: if no default is found users are presented with a scoped 'way' to launch something, thereby abstracting them away from specifics about launching
4. The launch dialog is only shown in dire cases, i.e. there is no context selected
Still some things to consider:
1. to toolbar button is behaving badly...needs some tuning
2. need an effective way to filter/change the 'Run' menu in response to preference changes
Created attachment 56849 [details]
work in progress
This patch build on all the rest with
1. toolbar button is working, pressing the button launches the current context, or prompts for the 'way' to launch, or prompts with the LCD if no context is available
2. the tooltip for the toolbar updates per context change (only if context launching is enabled)
3. ContextRunner has been updated to provided the status of context launching (on/off) and provide the name of the currently selected context
Still left:
1. the run menu
Created attachment 56854 [details]
Work in progress 6
Builds on the previous patches, changes the following:
1. Actions in the run menu and their text and icons now depend on context launching preference setting. The 'Run as' menu changes to 'Run' context launch. The 'Run...' action has it's text changed to 'Open Launch Dialog'. Same for debug actions.
2. The actions are now PropertyChangeListeners, so they update when the user changes the preference. However, I was unable to get the 'Run As' menu to be recreated.
3. Bug was found in ContextRunner where selecting the console or other views that produce a Selection but not a structured selection, resulted in CCE. Exception fixed with an instanceof, but because no context could be created, the run action will only open the launch dialog. We should improve this, perhaps by launching the last launched.
released the LaunchConfigurationWorkingCopy and LaunchManager API to HEAD, along with doc changes and changes to IConfigurationElementConstants released updated migration delegate code and associated tests to HEAD see JavaMigrationDelegate and MigrationDelegateTests Created attachment 57047 [details]
WIP
Patch includes all work thus far and:
1. excludes committed items
2. includes new scoping for launch configs in the resource property page
released ILaunchConfiguration adapter support for debug elements and the process console. Created attachment 57181 [details]
work in progress
updated patch with some menu tweaking and better ContextRunner logic
Created attachment 57350 [details]
work in progress
This patch continues the effort....
1. implements all discussed articles from the design doc ()
2. provides feedback and a choice if the context is not launchable
3. provides two new options for searching the project for a way to run if the context is not runnable, and what to do if the context is not runnable (and neither is the project)
Some caveats:
1. the run menu has been reverted to stay as it always is, this is because we cannot change it on the fly like the other menus, after enough clicking and opening/closing of the menu it will get into a 'broken' state (this should be addressed with the new menu implementation)
commited the work in progress to HEAD, and have made ongoing updates to the design doc, adding in some typical user scenarios. (http://dev.eclipse.org/viewcvs/index.cgi/*checkout*/platform-debug-home/r3_3/docs/Context-launching.htm?rev=HEAD&content-type=text/html) Also all of the changes for this bug have been flagged with the task tag CONTEXTLAUNCHING Is getDefaultLaunchShortcut is use yet? It looks like an important addition. For example when I select a file that's part of a C++ project and launch (no default launch config) I get the list of launch shortcuts that includes Java Applet, Java Application, JUnit Test, and JUnit Plug-in Test in addition to C++ Application. The ability to set the default shortcut for a resource (or its project) would prevent this. Not yet it is not, we are still deciding how to handle it to minimize the number of possible time you will be prompted. For example if we have a java project wih > 1 runnable, and we set the default way to launch the java shortcut, you will be prompted every single time you hit run, because we will need to know which runnable to launch. In some cases this is even an issue for selecting individual resources not only containers, for exmaple a java class with 3 inner classes which all have mains, you will be prompted. Any thoughts? Created attachment 58480 [details]
new hotness
After quite alot of testing the current offering for context sensitive launching, we have come to realize that it does not work as well as it could, and typically ends up with too much prompting when it seems like we could make better choices.
To this end, we have 'revamped' context launching to leverage launch histories and launch shortcuts, and make better assumptions about what is to be launched.
This patch is provides the new context launching thus far, and removes modifications to the main 'Run' menu and to the context menu (for now). So to test it you will have to use the main toolbar button only (again, for now).
The implementation of default launch configurations is still provided, and now there is a menu contribution on the 'Run As' menu that allows users to select to run the default.
Created attachment 58788 [details]
updated
updated patch which has better launch button label updates and a simple prompt for running parent projects.
I tried the patch and will keep experimenting but here is some early feedback: We need to be able to choose the default launch configuration to use for a resource based on other attributes of the resources (ie. the active build configuration for a project). It looks like we would be able to do this by listening for those attributes to change and then setting the default configuration for the resource (or more likely its parent project). But in the case where we decide there is no default launch configuration for a project then we would like to be able to provide a default launch shortcut instead of the user being presented with a list of possible shortcuts. Or even if the list of possible shortcuts could be limited just as you can filter most UI elements with Activities (is getActivityFilteredLaunchShortcuts used?). For that matter I wonder why the java shortcuts are showing up when the project (CDT) doesn't have a java nature. Note: with our new approach, we don't actually need default configurations. Instead, we use the launch history as a guide of what to launch based on which resource the user has selected or is editing. We determine which launch configurations are associated with the selected resource, and then look at the history to see which of those (if any) was most recently launched. We launch the most recently launched configuration associated with the resource. (The hover help also shows this). If no configs are in the MRU list, but there are configurations associated with the resource, we prompt the user to select from existing configurations to run. If there are no configs for the resource, we prompt with shortcuts. In this last case, a default shortcut would avoid prompting. A default config would also avoid prompting if the MRU list does not contain any of the associatd configs but configurations are associated with the resource. However, it might be confusing to mix "most recent" with "default". With the new approach it looks like we could have a shortcut's enablement expression check the active build configuration of a CDT project. That will restrict the scope of the MRU list to the appropriate types. Setting a default configuration wouldn't required. Can you change it to use the activity filtered list of shortcuts? Created attachment 58895 [details]
wip
further adds to the other patch, by removing unused methods, refining the way the tooltip updates, cleaning up the tests a bit
realeased current work to HEAD, with changes to launch tooltip updating added tracing and improved tooltip updating to HEAD changes released to bug 166231 now allow the getMRU method to correctly consider favorites when querying the launch history committed first round of polish items: 1. removed default launch configurations. These do not play well with the new story for context launching, and as such have been removed. The properties page is still available to be used to manage configurations associated with a resource. 2. reworked ContextRunner to do less work when the current context is needed (for launching and context label updating) 3. updated toolbar label to case where one launch shortcut applies: now it reads "<launch mode> <resource name>". e.g. "Run Main.java" 4 updated case where the workspace is emtpy and nothign would happen. Now shortcuts that work on empty selections are presented (if any) or a nice information message appears While I'm all for trying to make the Run/Debug actions more intuitive, and the scenarios in comment 6 make sense to me, I'm concerned that the new behaviour may be more confusing in cases where the set of active launch configs is not closely tied to the UI context the user is in (i.e. the code they're working on). For example, in my current work I have 5 launch configs: 1. a Plugin JUnit config that creates a test database (includes only a subset of the plugins in my workspace) 2. an Equinox config that runs a server that connects to the test database (also a subset) 3. an Eclipse Application config that runs our client (includes all plugins, though not all get used) 4 and 5. other ones just like 3, but with different -data directories Typically I launch 1, then 2, then 3. Say 2 fails because one of the server plugins has a compilation error. Say I fix it up by loading the most recent changes in the relevant projects. Currently, F11 will relaunch 2. Under the new proposal, it may relaunch 3 instead if I happen to be looking at code from the client (which is usually the case). For sure that I will set the preference for this so that I can keep the original behavior. Re comment#49 - this scenario is a multi-launch that we do not yet properly support (see bug 39900 that addresses the request). If we had a composite launch, this scenario might also work properly (i.e. one config that launched multiple configs). In 3.3, however, you may need to use the "classic" launching behavior to get things to work as you want. When working with other projects that have e.g. documentation, then I cannot launch directly (I get 'Run As...'). The user has no clue what's going on, e.g. it suggests to launch the target workbench (an Eclipse launch that I previously used) when I select the project 'org.eclipse.jdt.doc.user' but when I select the 'org.eclipse.pde.doc.user' project it doesn't - instead 'Run As...' is suggested. Why? Mmmh - actually it does also run the target when 'org.eclipse.pde.doc.user' is selected - only the hover was indicating the wrong thing. *** Bug 176850 has been marked as a duplicate of this bug. *** My run/debug launch configuration applies to remote executable object or process. For example, run/debug program on remote host or debug process on remote host. Remote object is NOT an IResource. Does this mean I can not take advantage of the proposed context launching ? Is there other way to determine the context mapping except using IResource ? (In reply to comment #55) > My run/debug launch configuration applies to remote executable object or > process. For example, run/debug program on remote host or debug process on > remote host. Remote object is NOT an IResource. > Does this mean I can not take advantage of the proposed context launching ? > Is there other way to determine the context mapping except using IResource ? Currently, conetxt launching is resource based. For 3.3, this is all we have planned. We may one to look at further enhancements to this in a future release to allow for context launching of non-resource based objects. Marking fixed & verified. New bugs should be opened for issues pertaining to context launching. New enhancement request #181204 is created for context launching with non resource based objects. As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since the originator of this enhancement/defect has an inactive Bugzilla account and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. Please ignore the previous comment. Marking verified. |