| Summary: | [EditorMgmt] File > Open File editor should also use content describer | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | David Whiteman <dlwhiteman> | ||||||||||
| Component: | UI | Assignee: | Dani Megert <daniel_megert> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | bokowski, daniel_megert, Darin_Swanson, Ed.Merks, nammoula, remy.suen, valentinbaciu | ||||||||||
| Version: | 3.4 | Flags: | bokowski:
review+
|
||||||||||
| Target Milestone: | 3.4 RC1 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Bug Depends on: | |||||||||||||
| Bug Blocks: | 199164 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
David Whiteman
Currently, content types are honored but only based on the file's name i.e. we don't look into the file. We need to use org.eclipse.core.runtime.content.IContentTypeMatcher.findContentTypesFor(InputStream, String). This is in class 'IDE'. Created attachment 99059 [details]
Use proper content type support to determine the editor ID for a file store
It seems to me that unless the file store's input stream is properly examined to determine the content type the open behavior for an external file will never properly match that of a file in the workspace. The attached patch directly addresses that shortcoming.
Sorry Ed, there was a little typo in my previous comment: you can simply use org.eclipse.core.runtime.content.IContentTypeMatcher.findContentTypeFor(InputStream, String) to get the preferred content type. Also, you should use openInputStream(EFS.NONE, null) instead of openInputStream(0, null) and of course ensure that the stream gets closed again. I'll attach a new patch shorty. Dani, would you like to take care of this one yourself? Sure. David, a simple test case based on Eclipse SDK would help to verify our fix. Created attachment 99064 [details]
Fix
Ed, can you give the patch a try as well? Created attachment 99076 [details]
Sample file to test opening correctly
This fix works well.
So the idea is to make this private method public for the next release?
To test I was opening the attached file named "customBuildCallbacks.xml". Without the fix it opens as text; with the fix, it opens using the ant editor.
Can the testcase be manual? I can tell you the steps to follow from the standard Eclipse SDK: 1. Create a new file called foo.xml in a project 2. In the Ant editor that opens, paste the following in the file and save it: <?xml version="1.0"?> <project default="main" basedir="."> <target name="main"/> </project> 3. Export the file to the file system 4. Choose File > Open File... from the menu bar and select the file you just exported (foo.xml) 5. Observe whether the Ant editor or the default XML editor is used >So the idea is to make this private method public for the next release?
Do you need it? If so, there's nothing against that - would by in sync with the other methods we already have as API.
No, I don't have any immediate need for it. It just looked to fit in so nicely as you said. So I assumed you just made it private for now because of API freeze and will make it public later... Created attachment 99116 [details] Fix Grrr! I hate that bug 148844! We need to rename that method, otherwise we force plug-ins to add additional required bundles. So, that leaves to patch to just tweak the getEditorId method. *** Bug 223064 has been marked as a duplicate of this bug. *** Committed to HEAD. Available in builds >= I20080508-2000. *** Bug 194935 has been marked as a duplicate of this bug. *** |