Community
Participate
Working Groups
Due to the way some WTP editors are specified in their plugin.xml declarations, replacing them with enhanced versions is nondeterministic. The problem is caused because some of the WTP editors specify themselves as the default editor for their content type. If an additional editor is also specified as the default, the one that is chosen by the platform for editing the content type cannot be predicted or controlled since it is dependent upon which order the plugins were initially loaded. Since WTP is intended as a platform for third-party tools and since it is not unreasonable to expect such tools to replace the editors provided with enhanced versions, I'm requesting that no WTP editors be specified as the default for their content type. This small change should not cause a problem with current functionality since the WTP-contributed editors will still be chosen if they remain the only editor for their content type, even if not set as the default. The following WTP editors currently specify themselves as the default editor for their content type (default="true"): org.eclipse.wst.html.core.htmlsource.source org.eclipse.wst.javascript.ui.internal.editor.JSMultiPageEditorPart org.eclipse.wst.rdb.internal.sqlscrapbook.editor.SQLScrapbookEditor org.eclipse.wst.server.ui.editor org.eclipse.wst.wsdl.ui.internal.WSDLEditor org.eclipse.wst.xml.ui.internal.tabletree.XMLMultiPageEditorPart org.eclipse.wst.xsd.ui.XSDEditor These editors do not specify themselves as the default and already comply with the request in the bug report as they are: org.eclipse.wst.css.core.csssource.source org.eclipse.wst.dtd.core.dtdsource.source org.eclipse.wst.rdb.data.internal.ui.editor.tableDataEditor org.eclipse.wst.rdb.server.extensions.editorlaunch.SQLEditorForServerExplorer org.eclipse.wst.rdb.sqleditor.SQLEditor org.eclipse.wst.sse.ui.StructuredTextEditor org.eclipse.wst.wsi.ui.internal.WSILogEditor I'm setting the initial severity to 'major' because this issue breaks the ability to reliably replace WTP-provided base functionality by adoptors of the frameworks.
Todd, this sounds like a "Hot Bug" for you. Correct? Can I assume that is how you'd like us to treat this?
Arthur, thanks very much for asking. Yes, I'd consider this "hot" for us since it limits our ability to adopt the platform in the way we'd like. However, we're currently working in the 1.5 timeline only, so resolution within the milestoning process of 1.5 would be sufficient for us.
Todd, OK, we'll add this to the 1.5 Hot Bug list. Jeffrey - pls add it. I'm assigning this to Lawrence as since it touches many components.
I'm adding David, Craig, Tim and Der Ping for comments as they own these editors.
Yes, this "base limitation" has long been an issue for many. See bug 73941. We in WTP can probably improve the situation for adopters. I'm a little concerned about the HTML one ... maybe xml too, I think we set default on those for the same reason Todd wants to, there are "conflicts" with "web browser" for HTML, and "ant editor" for xml (not sure that one still is due to fixes in ant component). My guess is others could be. Besides capabilities per se (as mentioned in bug 73941), there might be some approaches that rely on "branding", since products can define their own set of initial preferences to be set, so, perhaps products could set a "user preference" to make their editor the default. Todd, have you tried any "preference" approaches to custominzing your ueers experience?
> there might be some approaches that rely on "branding", since products can > define their own set of initial preferences to be set, so, perhaps products > could set a "user preference" to make their editor the default. Bug 15428 mentions such a preference: A product can specify the default editors for each extension or file name by setting "org.eclipse.ui/defaultEditors" in the file plugin_customization.ini. e.g., org.eclipse.ui/defaultEditors= *.ext1:editorId1;*.ext2:editorId2;fileName:editorId3 I could not really find more documentation on this preference. And I don't know if they've improved the preference since then to handle editors associated by content type.
>I think we set default on those for the same reason Todd wants to, >there are "conflicts" with "web browser" for HTML, and "ant editor" for xml >(not sure that one still is due to fixes in ant component). My guess is >others could be. To be sure we're on the same page, by "conflict" I'm assuming you mean that multiple editors are associated with the same file extension or content type. I agree that this is certainly the case in the "web browser" versus the HTML editor in WTP (the ant editor provides its own content type so should no longer conflict with other editors) and that there may be others. Additionally, a conflict such as this will be the case with any external plugin that tries to contribute an editor to an Eclipse install for which another editor already exists. I believe we're in complete agreement as to this problem statement. The issue is what can / should we do about it. I looked through my WTP development environment and searched the entire stack (including all prerequisites) for all editor contributions. Other than the editors I've already noted in this PR, the JDT's Java editor and the PDE's manifest/build.properties/plugin.xml multi-page editor are the only two specified as defaults. To be specific, that's out of the 20 extensions to org.eclipse.ui.editors I found in the SDK/EMF/GEF/JEM/XSD stack. In WTP alone, there have 7. The only reason I can think of for setting the WTP editors as the default is to disambiguate explicitly in order to provide an improved "out of the box" experience for an end user of WTP. This assumes, of course, that the end user actually always wants to edit an HTML file, rather than view it, for example. So, what's the tradeoff? At best, setting these editors as the default provides a small convenience to an end user as they then don't have to right-click and select Open With... or explicitly set the editor they want as the default using the platform's editor preferences. The downside, it becomes effectively impossible for anyone to contribute a plugin that provides a better default editor for any previously declared content type or file extension. This is a very small upside and an enourmous downside. As for the proposed workaround of using plugin_customization.ini, it has a couple of serious issues. First, it's only available if you actually ship an Eclipse product, not a plugin. Specifically, that means you can't launch Eclipse by running org.eclipse.sdk.ide, but must contribute and run a substitute. So, the number of add-in providers that this applies to is a vanishingly small set of the total. Second, even if you did this and provided the platform-specific startup program you'd need (like eclipse.exe), users could simply bypass all the customizations by running eclipse.exe directly instead of your launcher. I could easily see this being the case since every example shown about eclipse commandlines all reference "eclipse.exe". Given these two issues, I don't view this is a viable workaround. From this long post I hope you can all better understand my rationale in standing by my request that all of the default=true attributes be removed from all WTP edtiors. Please remember, the 'P' in WTP is *Platform* not *Product*.
Thanks for the long post, Todd. You raise some good points ... I'd never realized it was "painful" for adopters to provide their own "product". Its ironic too, the problem you (and we) are having with 'default' is the exact same problem as why 'default' was added to begin with! And, while us removing it might solve one level of problem, editor dis-ambiguation would still be a problem, so .. I've open bug 136945 to request some help re-thinking the general problem. Oh, and yes, we in WTP are well aware that P means Platform ... but, remember, the T means Tools :) Amy, can you please survey all the current uses of 'default' in WTP editors, and remove any that are not obviously required for dis-ambiguation at a "pure Callisto" level. Then, let's address the remaining after we know what remains (and, after Eclipse UI weighs in). Todd, to get specific, is it all seven that are causing you problems? Or some specific subset? (And, I know, your request is one of general principle ... but, I want to be sure we are solving specific problems). Thanks, all.
>Thanks for the long post, Todd. No problem. They're actually a strength of mine, which I will again demonstrate. ;-) >You raise some good points ... I'd never realized it was >"painful" for adopters to provide their own "product". Thank you. But, I don't believe I said it was "painful"; it's simply inappropriate for the vast majority of Eclipse extensions. Imagine two very focused extensions, one that adds a great XML editor, and the other that adds an exceptional HTML editor. Each would want their new editor to be the default because, afterall, that's why their users would've installed them. However, the "product" workaround to set the default editors certainly wouldn't work since only one product can be run at a time; it prevents the mixing and matching of features from different sources. Also, users would probably rebel at having to run a product anyway, since they think they just added a couple of extensions to the base Eclipse, not installed new "products". >Todd, to get specific, is it all seven that are causing you problems? >Or some specific subset? Our adoption specifically is hindered by the defualt settings on the Javascript, HTML/JSP, and XML editors. >(And, I know, your request is one of general >principle but, I want to be sure we are solving specific problems). I understand completely. I don't generally engage in theoretical pontifications. My only guiding principle is "deliver commercial product". :-) However, I also am fortunate enough to be a representative of the "add-in" proivder community on the Eclipse board. This is why I brought up the example above of two small providers that contribute only new editors as an example. This issue is larger than what affects my specific product; it can affect all add-in providers that want to improve the built-in editors. By setting the default in any of the WTP editors you're effectively guaranteeing that the "out of box" experience is of the default editors. Users might not even know that improved editors had been installed. Again, from my last post, the upside is a minor convenience item for Eclipse end users with a downside of making adoption extremely problematic. I'll close with a quote from the Eclipse development process (http://www.eclipse.org/projects/dev_process/validation-phase.php): "2 It is essential for an Eclipse project to have both an extensible framework and exemplary tools. However, if one had to prioritize between the two, an extensible framework is more important - Eclipse is about enabling the ecosystem rather than just about giving away free tools." I continue to reiterate my request to remove all the "default" settings from the WTP edtors listed.
>So, what's the tradeoff? At best, setting these editors as the default provides >a small convenience to an end user Is it truly a small convenience for the WTP end user? Will the WTP editor open and will an end user even know that a "better" editor exists for HTML than the text editor when WTP is installed? (Simply a question. I agree with your platform importance point.) One scenario I haven't heard mentioned is that of multiple adopters building on WTP. Say, for example, 2 adopters provide plug-ins with "better" HTML editors. If both these add in providers specify their editor as the default there is no gaurantee that one will open before the other. I will suggest that in this case the user has explicitly installed two adopter plug-ins so it's not unreasonable to expect them to then select the editor they want to use. On a more general note, I've seen the problem of default editors arise before. Perhaps what we need is a change in the platform to allow specifying both a default and a preferred editor. The default would be used if no other preferred or default editors are specified. The preferred editor would be used if specified. Really this would just provide two tiers of default editors but would allow for nicer functionality for Eclipse projects without hindering extension of the projects.
Server editor was default="true" for historical reasons (there was another editor for the same file type that conflicted). Since this is no longer the case, I'll remove it for 1.5.
First off, I want to say, I agree with what Lawrence said that it doesn't seem unreasonable to ask the user to explicitly specify their default editor to the better editor if they specifically installed this newer, better editor. That being said though, here are my findings: For reference, according to bug #91966, here is the resolution order for editors: Traditional filename/extension bindings that are declared default Content type bindings Traditional filename/extension bindings that are not declared default Here are the WTP editors that set default="true" (same as Todd said with the addition of the WSI Log Editor): -org.eclipse.wst.html.core.htmlsource.source Removable. Conflicts with Web Browser, but according to resolution order, html editor will take precedence over browser because html editor uses content type bindings whereas browser editor uses traditional filename binding and is not declared default. -org.eclipse.wst.javascript.ui.internal.editor.JSMultiPageEditorPart Removable. It looks like there is no other js editor in callipso -org.eclipse.wst.rdb.internal.sqlscrapbook.editor.SQLScrapbookEditor Unsure. This editor conflicts with org.eclipse.wst.rdb.sqleditor.SQLEditor. Both list a *.sql editor. -org.eclipse.wst.server.ui.editor Removable. See Tim's comment #11. -org.eclipse.wst.wsdl.ui.internal.WSDLEditor Removable. It looks like there is no other wsdl editor in callipso. -org.eclipse.wst.xml.ui.internal.tabletree.XMLMultiPageEditorPart Removable. Only conflict I found was with editing *.xmi. org.eclipse.emf.ecore.presentation.ReflectiveEditorID is another *.xmi editor. But according to resolution order, xml editor will take precedence over Reflective Ecore editor because xml editor uses content type bindings whereas Reflective Ecore editor uses traditional filename binding and is not declared default. -org.eclipse.wst.xsd.ui.XSDEditor Removable. Conflicts with org.eclipse.xsd.presentation.XSDEditorID, but according to resolution order, xsd editor will take precedence over Sample XSD editor because xsd editor uses content type bindings whereas Sample XSD editor uses traditional filename binding and is not declared default. -org.eclipse.wst.wsi.ui.internal.WSILogEditor Removable. It looks like there is no other wsimsg editor in callipso I will remove all the default="true" attributes where I said they were "Removable" for 1.5 unless someone objects. The only ones I will not touch are: -org.eclipse.wst.server.ui.editor - since Tim said he'd remove it. -org.eclipse.wst.rdb.internal.sqlscrapbook.editor.SQLScrapbookEditor - since I am unsure. Der Ping, could you please evaluate since both conflicting editors seem to be rdb editors?
Amy, one question about your strategy. Several of WTP's editors will currently be used as the default as they use content type bindings and conflicting editors use traditional filename binding. Will this strategy hold up if the other editors update their declaration to use content type? Have you spoken to any of the other editor owners to know if they have plans to update their declarations?
Are you talking about the other editors that might conflict with the WTP ones? Those 3 are: Web Browser (html) Reflective Ecore editor (xmi) Sample XSD editor (xsd) For all 3 cases, their respective content types are not declared at their level. For example, it is wtp's html.core that declares an html content type to associate with wtp's html editor. So before those editors are associated with a content type, they need to first define one. If they define their own content type and it conflicts with ours, then we have bigger problems than just what is the default editor.
OK. It sounds like we'll get a heads up either way. I just don't think we should blindly rely on the currect pattern as it may change. I think it's better to start the conversation with these editor owners ourselves so all interested parties are informed of the current state of affairs and so we can coordinate changes in the future. Thanks for the detailed report on the editors. Looks like default can be safely removed from most or all of our editors at this point. Der-Ping - The RDB editors are the last ones we need to deal with. Can you please comment on the RDB editors' use of default?
Assigning to RC2. According to [1], RC1 == M6. [1]http://wiki.eclipse.org/index.php?title=Web_Tools_Requirements_1.5#Release_milestones_and_release_candidates
I just checked in and released changes to the following plugins: html.ui javascript.ui sse.ui.tests wsdl.ui xml.ui xsd.ui *rdb.sqlscrapbook **wsi.ui All I did was remove 'default="true"' from the editor definitions. *Der Ping, I went ahead and removed the default=true from the SQL Scrapbook editor. If you feel it needs to be added back in, feel free to open a new bug and explain why you feel it needs to be added back in. **I spoke too soon about the wsimsg editor. I noticed since wsimsg is XML Content type, the XML editor will be the default editor instead of the WSI Log Editor. However, it looks like the WSI Log editor is exactly the XML editor (except for the icon) so I wonder if this editor is even necessary. I opened bug 137539 to track this issue. I still went ahead and took out the default="true"
Thanks for handling the removal of default=true from the editors Amy. I'm changing this defect to resolved as all the editors Todd identified no longer are defined as default.
I'm nominating this as a great bug. Todd identified an adopter problem with the definition of WTP's editors that had not previously been considered. Todd compiled a detailed list of offending editors and offered a solution to the problem. This defect spanned editors owned by three WTP teams but with amazing coordination (and Amy's helping hand) was discussed and resolved in 7 days. Although assigned to me, Amy should get credit for the fix in the great bug contest as she was responsible for implementing the changes.
I simply wanted to add my sincere thanks to everyone for their prompt attention, cogent replies, and rapid remedy for this issue. This really has been a shining example of what makes the Eclipse community special.
Marking as verified in 1.5RC3
Thanks for verifying Todd. Closing bug.
I have same issue with WTP XSL Editor. We need to override with our editor, but default is set to true for WTP XSL Editor. Please remove it.
(In reply to comment #23) > I have same issue with WTP XSL Editor. We need to override with our editor, but > default is set to true for WTP XSL Editor. Please remove it. Since this bug has been 'closed' for 4 years, I suggest you open a new bug with your request. You should also clarify who "we" are ... since such a request will reduce usability for some users, it would be nice to know for whom it is increasing usability. Thanks,
New Gerrit change created: https://git.eclipse.org/r/107771
