Bugzilla – Full Text Bug Listing
| Summary: | [EditorMgmt] old getDefaultEditor API is not backwards compatible (in spirit) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Billy Biggs <billy.biggs> | ||||||
| Component: | UI | Assignee: | Kim Horne <eclipse> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | critical | ||||||||
| Priority: | P3 | CC: | eclipse, Michael.Valenta, michaelvanmeekeren | ||||||
| Version: | 3.1 | ||||||||
| Target Milestone: | 3.1 RC2 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux-GTK | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Billy Biggs
This is indeed very odd. I see the same problem on GTK. Also, I can get highlighting in my XP development environment but not in my runtime which makes it hard to figure out why it works on windows and not on GTK. I will continue to investigate. I have found the problem (or at least a workaround which shoiuld point to the problem). The *.java entry is missing from the General/Editors/File Associations page. If you manually add it and make the Java editor the default, it will work. In my old workspace it was there but in newer workspaces, it is not. Rafael tells me that the UI should find the right editor even without the file association so I'm moving this to UI and marking as critical as it is a regression from the 3.0 behavior. How are you looking for the editor? It's in the OpenRemotgeFileAction of the CVS UI plugin. Bascially, we call IEditorRegistry#getDefaultEditor(String filename). In order for this to work you'll need to start using getDefaultEditor(filename, content type) - the new editor bindings can only be resolved when the content type is known. You'll need to pass the contents of the file to IContentTypeManager.findContentTypeFor(inputstream, filename) to determine this. I assumed getDefaultEditor(filename) would do a IContentTypeManager#findContentTypeFor(filename) for free if one could not be found. Couldn't that be done? That allow old clients to work together with new editors. After a powwow with Michael V, MvM and Nick we've decided that's what we'll do. We'll ask the content manager to "best guess" based on the filename and an empty input stream and use that in the old API to get the default editor. Re: comment 7. Kim, you don't need to provide an empty stream. There is API that will take the file name only. Also, just to make sure, you will do that only if there is no legacy editor associated to that file name, correct? Rafael: no, I would do this in the event people were using the old (non-content type qualified) API. If there were any legacy editors associated with the file they'd take priority anyway so it wouldn't be an issue. Created attachment 22220 [details]
Patch against org.eclipse.ui.workbench
Patch to address the issue
Created attachment 22222 [details]
Patch against org.eclipse.ui.tests
Updated testcases to confirm behaviour.
Patches applied. Verified in I20050610-0010 |