Bugzilla – Full Text Bug Listing
| Summary: | Prototype new project wizard | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | Greg Watson <g.watson> | ||||||||||
| Component: | RDT | Assignee: | Chris Recoskie <recoskie> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Greg Watson <g.watson> | ||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | mikekucera | ||||||||||
| Version: | 3.0 | ||||||||||||
| Target Milestone: | --- | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | 239079, 293079 | ||||||||||||
| Bug Blocks: | 293929 | ||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 141505 [details]
new cdt interface
Thanks Greg, I'm going to take a look at the patch, make whatever modifications are needed and get this committed. One thing we discussed, the user should have the option to select an existing service configuration or create a new one. I'm thinking of adding two radio buttons above the new service model widget on the third page of the wizard: - "Use an existing configuration". Choosing this will enable a combo box that lists existing configurations. When the user selects one it will become editable in the service model widget. - "Create a new configuration". This will enable a text box for the name of the config, which defaults to the project name. The config will be initialized with sensible defaults for the RDT providers. The user can use the widget to configure additional providers, (Or if I'm not mistaken the user can run the service model wizard after the project is created). In most cases the user can just click Finish on this page without having to edit anything. Also, what is the purpose of the project location service, I'm not sure I understand that. I just committed a ServiceConfigurationSelectionWidget that you can use to select/add/remove/rename service configurations. I'm still working on the implementation, but you can get the general idea. I'm happy to continue to work on it if you do the new project wizard. Since services are things that get configured via wizard pages, I had the idea that we could use a project location service to manage the project location configuration in a standard manner. Anything that needed the location of the project could query the service for this information, rather than having to delve into the innards of a project. Your call if you want to use it or not (In reply to comment #3) > Since services are things that get configured via wizard pages, I had the idea > that we could use a project location service to manage the project location > configuration in a standard manner. Anything that needed the location of the > project could query the service for this information, rather than having to > delve into the innards of a project. Your call if you want to use it or not That is not a bad idea, as then we have one less tie to the CDT wizard system. I'm not sure if/how things have changed due to the work you and Mike have done so far, but the original wizard pages for RDT were all contributed via CDT's custom wizard pages extension point. In theory if at some point you make it so all the data used by the wizard no longer is stored via the page property mechanism in the custom wizard page manager, then we could use these pages in non-CDT wizards. (In reply to comment #3) Ok, correct me if I'm wrong. It seems the issue is that you can't actually tell if a project is local or remote from the project's location URI. For example the 'file' scheme can be used to access a remote system over NFS, and the 'rse' scheme can be used to access the local file system. So we need to ask the user if the project is local or remote, and then provide a service to get at that information. Am I on the right track? There are a couple caveats to this approach though. First of all what if the user disables this service? Perhaps we should make it so that certain services cannot be disabled. Its also complicated by the fact that a configuration can now be shared amongst several projects. The API is unclear as to what getProjectLocationURI() should return in this scenario. Also the projects that share a configuration must be either all local or all remote. I guess this is Ok though, as the service providers we have now require connection info, so hthe projects that share a config must all be on the same connection anyway. (This is making me think that new configs should be named after the connection, not the project). Created attachment 148169 [details]
preliminary patch 1
This patch contains the new wizard but its still a work in progress. Greg can you please review this and let me know if you like it. I did it quickly and I can change it easily at this point.
I kept the first page of the wizard for selecting project name and location because it didn't require any additional work and because its consistent with the other new project wizards in eclipse. The third page allows the user to create a new service configuration or add the project to an existing one. If you choose a new configuration the defaults are set up correctly based on the connection the user selected on the first page.
After discussions with NCSA last week, I think we need to do this a bit differently. Their preferred approach is to make pre-configured service configurations available to users. Rather than choosing a connection, they would prefer users select the configuration they wish to use as the first part of the new project creation. They still have to choose the project path of course, but would like everything else to be set up based on the configuration. I plan to add support to remote tools so that the connections can be automatically (re)created using this information. We could either do this through a separate wizard, or modify this wizard. Depends on the model you think your users will want. One thought might be to use the current provider/connection combos if there are no service configurations, or a list of the available configurations if there are any (along with a New... button to create a new connection if desired). Created attachment 151066 [details]
updated new project wizard
Here is an updated version of the patch that uses the new service widgets.
I haven't changed the selection of the initial connection, and left the service configuration as the last page. This is probably adequate for now.
I get this in the error log when trying to switch to the remote tools index provider: java.lang.IllegalArgumentException at org.eclipse.ptp.rdt.ui.wizards.RemoteCIndexServiceProvider2Contributer.configureServiceProvider(RemoteCIndexServiceProvider2Contributer.java:61) at org.eclipse.ptp.services.ui.widgets.ServiceProviderConfigurationWidget.selectProvider(ServiceProviderConfigurationWidget.java:502) at org.eclipse.ptp.services.ui.widgets.ServiceProviderConfigurationWidget.access$6(ServiceProviderConfigurationWidget.java:479) at org.eclipse.ptp.services.ui.widgets.ServiceProviderConfigurationWidget$6.widgetSelected(ServiceProviderConfigurationWidget.java:197) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:228) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at org.eclipse.ptp.services.ui.widgets.AddServiceConfigurationWidget$4.widgetSelected(AddServiceConfigurationWidget.java:158) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:228) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at org.eclipse.ui.internal.actions.NewWizardShortcutAction.run(NewWizardShortcutAction.java:135) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1003) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3880) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) at org.eclipse.equinox.launcher.Main.run(Main.java:1311) at org.eclipse.equinox.launcher.Main.main(Main.java:1287) I've quickly reviewed the patch. I definitely think the new wizard is a huge improvement over the old one. I wasn't able to test the remote tools indexing provider though because of the above bug. It seems that part of the patch has already been committed. The rest of the patch just contains the new wizard. My only concern about the patch is that the code needs to be cleaned up and documented. It took me a while to realize that RemoteCIndexServiceProvider is for RSE and RemoteCIndexServiceProvider2 is for RemoteTools, some better naming or docs would help there. It also seems to contain a couple superfluous files like "copy of plugin.xml". Greg do you plan on removing the older RSE index provider? (In reply to comment #10) > Greg do you plan on removing the older RSE index > provider? Veto from me on anything that does that. IBM needs to retain the ability to use RDT on un-wrapped RSE connections. We need to be able to share connections with other tooling that is using RSE. I was going to leave the old one anyway. I'll take another look at the patch and update it. It's possible some last minute changes broke it. I've committed the new new project wizard. I've also renamed RemoteCIndex*2 to RemoteToolsCIndex* and RemoteCIndex* to RSECIndex* to distinguish the Remote Tools and RSE versions. |
Created attachment 141504 [details] prototype new project wizard plus new service providers Here is a prototype new project wizard that will give us much more flexibility to customize the configuration of remote projects. I've tried to reuse as much of the CDT infrastructure as possible, but because of the whole mess that it is, it requires a new CDT interface. Please take a look at let me know if this seems like a good approach. Note: this uses the new core service provider infrastructure. Please make sure you have org.eclipse.ptp.services.* in your workspace. Also, I haven't completed transitioning RDT to the new services so the remote project will not actually work. You'll see an error that the indexer is not configured when the project is created. If you think it's a good approach, I'll fix up these problems.