Bugzilla – Full Text Bug Listing
| Summary: | [Commands] request: add commands to open/show resource with path parameter | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Christopher Daly <cjdaly> | ||||||
| Component: | UI | Assignee: | Douglas Pollock <douglas.pollock> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | CC: | larryisaacs, pwebster, Szymon.Brandys | ||||||
| Version: | 3.2 | ||||||||
| Target Milestone: | 3.2 M5 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Christopher Daly
Created attachment 33959 [details]
patch with openFileByPath / showResourceByPath commands
The patch is good, but I've made a small change. I merged the open resource command you provided with the open resource command already provided by org.eclipse.ui.ide. This command's id is "org.eclipse.ui.navigate.openResource". By implementing enough interfaces, it is possible to put use this handler in the default case, as well as including it in an action set. So, without parameters, it prompts the user. With parameters it opens the given resource. This is not easy for me to verify. Chris: is this working for you guys? I'm actually seeing a problem with org.eclipse.ui.navigate.openResource. The parameters get lost so you always get the open file dialog instead of opening the file specified with the filePath parameter. I'm going to look into this more and try to figure out what the proper fix is. I hope we can get a fix in for M5. The problem might be that an action still has "org.eclipse.ui.navigate.openResource" set as it's definitionId. See the action with id org.eclipse.ui.OpenWorkspaceFile in the plugin.xml in org.eclipse.ui.ide. So the fix might be as simple as clearing that definitionId line. I don't have a recent I-build at the moment. I'm going to download one and checkout org.eclipse.ui.ide so I can try this. What I'm noticing is we get into ActionDelegateHandlerProxy.execute(ExecutionEvent) and that calls one of several delegate.runX() methods. But this doesn't pass along the ExecutionEvent, so the parameters are effectively thrown away at this point. I suspect removing the definitionId would get us directly to the handler without going through ActionDelegateHandlerProxy. Yes, it would. Can you try that change and let me know? If it works for you, I'll commit it for 3.2 M5. Created attachment 34727 [details]
removed definitionId from action org.eclipse.ui.OpenWorkspaceFile
Ok, the fix discussed above works. It's a one line change, but here's a patch anyway.
Fixed in CVS. Chris: does this work for you in I20060216-1200 or later? I just checked I20060216-1200 and it is now working correctly there. Chris, this might be an odd question, but what do you do to get the parameter into the ExecutionEvent? PW I'm not sure I understand your question, but maybe this helps: Look at CommandManager.deserialize(...) and see how it composes a ParameterizedCommand with the command id and the various parameters. Once you have the ParameterizedCommand you can call executeWithChecks(...). So you don't need to touch the ExecutionEvent yourself. Thanx, Chris, but I'm more interested in what causes this parameter to be added in the first place. What user action, what usecase, would cause a command with this parameter to be generated? Is it used for testing? Later, PW Hi Paul, see bug 123921 for more on the rationale for adding the parameter to this command. An example might be something like this: -the user has imported a sample into the workspace -help or a cheatsheet content associated with the sample has some text with a link to content in the sample -when user clicks the link, some file in the sample is opened. So for example a cheatsheet might say, "now you need to add a dependency to your plugin. click _here_ to open the plugin manifest editor and then select the Dependencies tab....". Where the _here_ link specifies the path of the plugin.xml in the sample project. Ah, thanx Chris. So something like this is really useful for UA. PW I could not get "org.eclipse.ui.navigate.openResource" to work from a cheat sheet. Upon investigation I found that no parameters reached the command handler. Just as described in this bug. I see the patch removes the definitionID from the "org.eclipse.ui.OpenWorkspaceFile" action, however in my Eclipse 3.2 (M20060629-1905) it is still present. To finish the prior comment, the fix for Bug 134834 added the definitionId back in and it is still present at HEAD. Though I have been debugging this with Eclipse 3.4.2, I think it likely this is still broken in Eclipse 3.5. Perhaps this bug should be re-opened. Fortunately for the Hello World Plug-in cheat sheet provided by PDE, if focus is in the plug-in manifest editor, the "org.eclipse.ui.navigate.openResource" command works since the handler is HandlerProxy instead of ActionDelegateHandlerProxy. However, it would be useful to get this working reliably for all use cases. For now, I can work around the problem by dup'ing the "org.eclipse.ui.navigate.openResource" command in my own plug-in and assigning it a new ID, then using that one in my cheat sheet. |