Bugzilla – Full Text Bug Listing
| Summary: | [EditorMgmt] resolution policy for editors needs to be revamped to accomodate content types | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Kim Horne <eclipse> | ||||||
| Component: | UI | Assignee: | Kim Horne <eclipse> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | andre_weinand, daniel_megert, Darin_Swanson, david_williams, eclipse, for.work.things, gsmith, jens.lukowski, michaelvanmeekeren, mlists, thatnitind, victor.toni | ||||||
| Version: | 3.1 | ||||||||
| Target Milestone: | 3.1 RC1 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 89240 | ||||||||
| Attachments: |
|
||||||||
|
Description
Kim Horne
I'm concerned that with the release of 3.1 fast approaching that the planned editor page revamp won't get done. With this in mind, resolving this becomes even more important - if the user doesn't have a means to override any content-type bindings declared by plugin.xml files then they're going to get quite frustrated. I'd like to go with the following resolution order: 1) any traditional filename mapping 2) any direct content-type mapping 3) any traditional file-extension mapping 4) any ancesteral content-type mapping This would allow the user to always override any content-type binding with an explict filename binding. I believe the above policy might be adequate for 3.1, but there is definite improvement we could make for 3.2. Does anyone have any objections to this policy? Created attachment 21328 [details]
Work-in-progress patch
After discussing it a bit more, I'm tending to think that we should give priority to both styles of traditional bindings, making the order : 1) any traditional filename mapping 2) any traditional file-extension mapping 3) any direct content-type mapping 4) any ancesteral content-type mapping This gives full backward compatibility until we can get our story straight in 3.2. +1 This has the benefit that associations created by the user in the preferences will have priority over content-types and not cause confusion, however appropriate editors will show up on the Open With menu (for example) via content-type resolution. Created attachment 21335 [details]
Replacement for the above patch that changes the ordering
Is the "default" attribute for editors using only content type associations still effective (if it is the only default found)? And what happens if only content type-based editors are eligible for a given file name? Do you still pick the standard text editor in that case? Also, we are concerned with legacy plug-ins and providing users a way of controlling user-driven editor association, what I am campletely in favor. It might be too late for that, but I would rather see the extensions/filenames attributes in the contributions to the editors extension point deprecated. I am concerned that we are making not a very compelling case for people to adopt the new content type association. There is no story matching the "default" attribute to the content type bindings. That will have to come later. The default "default" editor case that you mentioned is OK - if there is a content type binding for a given file then it will be used instead of the text editor. I don't want to deprecate the old attributes until we have this story ironed out to a satisfactory degree. Deprecating them when there are so many questions left to answer seems unwise. I wouldn't be adverse to altering the doc for them saying that they may be deprecated in the next release, however. What if the user removes the contributed editor/content-type association from the 'File Associations' preference page? Will it still be in effect even though it does not appear on the preference page? We should at least not allow to remove it then. Are editor contributors expected to keep the existing 'filenames' and/or 'extensions' attributes or do we have to remove them in order to work correctly for 3.2? As it stands, the contentType->editor association isn't reflected in the preference page and likely won't be for 3.2. If the user were to go to the content type page and remove the association between the filename/ extension and the content type then of course it wouldn't be used. I would expect that SDK editors should remove the old filename/extension attributes for 3.1. They'll still work, but we do want to encourage people that content types are the wave of the future (so to speak). Since there is no default attribute for content type bindings, does that mean there is absolutely no way for content type mapping to override file extension mapping? For example: Web Browser editor - just opens a file in web browser - supports *.html file extension HTML editor - edits html files - supports html content type Web browser will always open all html files. At least if content type mapping had precedence over file extension mapping, then editor contributors who use file extension mapping can still use the default attribute to say use their editor by default. Also, since bug 91965 will probably not be fixed in 3.1, there's no way for users to directly map a content type to editor and say use that editor by default. Versus users having the ability to say use another editor by default for a file extension. Preference page-wise, users see: Content Type Content type associated to file type File Associations File type associated to editor It might help if at least the editors associated to content type which are associated to file types also show up in the file associations page. That way users have a little more control over the proposed resolution policy (by being able to set default editor). So back to my web browser, html editor example, users currently see: Content Type html content type -> *.html File Associations *.html -> web browser (what they dont see till they do "Open with" is that html editor is associated with *.html files as well) I propose: Content Type html content type -> *.html File Associations *.html -> web browser, html editor re: comment #10 , once we decide we should also log bugs against the other editors re comment #11: Amy - there would be no way for content type editors to take priority. The solution for the user would be to remove the binding to the WebBrowser editor in the preference page. With no traditional style bindings the content type bindings would take effect. re comment #12: Hmm. That might be a good compromise for 3.1. I'll investigate that. I've gone and checked in the proposed changes to the resolution policy. I'd appreciate it if any interested parties would download the next good build and give them a spin. re comment 9/10: I was asking what happens if the editor is removed on the 'File Associations' pref page not the extension/name on the 'Content Types' one. I guess currently it will simply disappear (see also comment further down). re comment 13: the bugs to switch to content-types already exist against the editor contributors (see bug 89232 and its dependants) that's why I asked what we have to do regarding the 'extensions' and 'filenames' attributes is ;-) re comment 12/14: I like the suggestion to show more info on the 'File Associations' page. This would allow to resolve the problem when the user tries to remove the content type contribution: it could be prevented (locked) like on the 'Content Type' page. I've added a patch to bug 91965 that implements the suggestions that Amy has made. They're a little rough around the edges so I won't be checking them in just yet. I'm with Rafael on comment 6, it seems counter-intuitive that an editor associated to the .html filename extension but not as the default will "win" over an editor registered as the default for an HTML content type including .html. Such is the case with the Web Browser and WTP's HTML editor--which we'd intended to associated only by content type as was recommended. This makes switching over very unappealing for 3.1. Unfortunately the EditorRegistry looses far too much information when it reads from the registry. We have no way of knowing if an editor is default because it's tagged as such or because it happens to be the only editor associated with a filename/extension. Fixing this for 3.1 seems far too risky as it would require some major reconstruction and possibly new API. Marking as fixed for 3.1. Please log any requests for changes to the current behaviour as new PRs (assigned to me) and I'll investigate post 3.1. Verified as fixed for I20050527-0010 *** Bug 97760 has been marked as a duplicate of this bug. *** The behavior will be changing once more for 3.1 as a result of bug 97811. Essentially the concerns Rafael and Nitin will be addressed. The new resolution order will be: Traditional filename/extension bindings that are declared default Content type bindings Traditional filename/extension bindings that are no declared default |