Community
Participate
Working Groups
Requested by the UI team: Currently, the content type registry only allows content types to be added through extensions provided by plug-ins. Users should be able to add new content types when needed, as is the case on Windows (flat list) and KDE (mime-type-like two-level hierarchy).
Content types form an underlying mechanism only visible/interesting to tools (and optionally to advanced users) where a file association registry can be built on. Thus, there is no need to provide user-defined content types.
Reopening for consideration (see bug 69647).
This must resolved for good in a way or another.
MVM/Doug, could you please elaborate on use cases for this request providing counterarguments? Thanks. My view on this has always been: Many things in Eclipse should be content type aware (editors/views/comparison editors/...) - the relationship between those things and content types is established by plug-in providers during development time (e.g. this view can handle the HTML content type, this editor can handle the XML content type, etc). If the user has weirdly named files such as HTML files with .HT1 extensions, s/he can (once UI is in place) always change the content type definition for HTML and add .ht1 as a user-defined file-extension, instead of creating a new content type. The important fact here is that if the file the user wants to see/manipulate is not related to any known content type, no view/editor will know how to open it, so there is no point in allowing users to add content types. Legacy things will not be associated to content types, they will be associated to file names/extensions. Programatically creating content types to handle these cases does not make sense, since there is no way to derive content type information from file names/file-specs. So every mechanism currently keeping file associations (editors being the most importante case) need to provide backward compatibility in an ad-hoc way. For external programs that handle files for which no content type has been defined, the same thing applies.
Kim, please consider comment 4 was addressed to you too.
Deferring to M6 since work in the UI side of the problem was deferred. Adding Sebastian since he is looking into this now.
No plans to do this.
*** Bug 98230 has been marked as a duplicate of this bug. ***
We should probably investigate this in 3.2
Legacy associations should be content types just like any other (one file extension per legacy content type). Although a programmatic content-type-recognizer can only be contributed via extension point, the user should be able to change relationships between existing content types and to contribute new content types that can be recognized entirely by filename (for example, if I'm not interested in distinguishing between different C++ files, I should be able to create a new content type for .CPP files). Creating this as a content type is preferable to a legacy association because a CPP content type could inherit all the text file behaviors but a legacy association can't. Also, the UI is confusing if legacy stuff is completely different than content types. Thinking in the distant future: Even in the case where the file contents need to be examined, it should be possible to support user-defined content types. We could allow content type recognizer criteria to be plugged in via extension point. For example: 1. A plugin contributes content type criteria that can disambiguate XML files based on their DTD. 2. A user goes to the content types page and clicks "add" to add a new content type that is a subtype of XML. 3. They are asked for the name of their content type. They call it "MyApp script file" 4. They are asked "How can you recognize this file type?". At this point, we show the list of possible criteria that apply to XML files. For example, the list might contain "by filename" or "by native MIME type", and "by XML DTD". The last option would have been contributed by the extension in 1. 5. They specify "by DTD". At this point, we load the extension from 1 that prompts the user for a DTD URL. 6. The user clicks "finish", and they now have a new user-defined content type that can recognize XML files that make use of a specific DTD.
"...if I'm not interested in distinguishing between different C++ files, I should be able to create a new content type for .CPP files). " You don't need to do that. That would be equivalent to adding the *.C and *.CPP file specs to the Text content type (already supported). What is the value of creating a separate content type for that? There will be no piece of code in Eclipse that knows how to handle C++ files specifically anyway.
There are two reasons I'd want to do that: 1. Inheritance. If I want to create an association that applies to all text files, I can do so once by creating an association with the "text" content type, rather than needing to create it once for *.txt, once for *.cpp, once for *.java, etc. 2. UI consistency. I shouldn't need to use one UI for creating "old-style" associations and one for "new-style" associations. Here's what went through my head the first time I saw the content types page: - This looks like a really powerful way to set up editor associations. - ...but they aren't used in the editor associations page, so what's the point of content types? - ...and what's the point of having a preference page for them if I can't change them? My first reaction was good, but I was left confused about what a content type was and what it was used for. I figured it out eventually because I had the Eclipse source in front of me and the test plan required me to figure it out... but I suspect most users would have given up at that point. Regarding my .CPP example: Eclipse supports embedded OLE editors and can create associations with external apps. I have many windows apps that DO know how to deal with .CPP files, and it's quite reasonable that I'd want to launch them from Eclipse. It's also possible that I've installed 3rd-party plugins that know how to deal with .CPP extensions and that I just want to control which one gets selected. Perhaps the extension was an old-style editor that isn't aware of content types, and I want to tell Eclipse that its *.cpp files are actually a subtype of text files... or perhaps I've installed multiple content-type-aware plugins from different vendors and I just want to control which gets precidence.
"1. Inheritance. If I want to create an association that applies to all text files, I can do so once by creating an association with the "text" content type, rather than needing to create it once for *.txt, once for *.cpp, once for *.java, etc." Yes, this is exactly how it works today. Right now only plug-in providers can associate an editor to a content type, but I guess in 3.2 there will be UI for that. See below. "2. UI consistency. I shouldn't need to use one UI for creating "old-style" associations and one for "new-style" associations." I also agree. Again, this is a problem that will hopefully be fixed in 3.2, but I don't agree user-driven creation of content types must be the only solution. Everything works fine except for this presentation problem. "- ...but they aren't used in the editor associations page, so what's the point of content types?" Kim is working on improving that (check out tonight's build). We won't have the final solution for 3.1 though. "...and what's the point of having a preference page for them if I can't change them?" I don't know what you mean here. You can change content type file specs, and that will affect editor resolution. "perhaps I've installed multiple content-type-aware plugins from different vendors and I just want to control which gets precidence" This does not have anything to do with allowing users to add content types, does it?
"This does not have anything to do with allowing users to add content types, does it?" True, but it does have to do with bug 98230 which was flagged as a dupe and additionally requests that users be able to rearrange existing content types. Two plugins may not know about one another, but a content types declared in one may be a generalization (or duplicate) of a content type declared in the other.
Stefan, you might want to open a separate enhancement request against Platform/Runtime for that. Please provide sound use cases for that. Thanks.
Stefan: if you create a new bug, could you please CC me on it? Why again does Platform/Runtime feel that content types should not be allowed to add content types programmatically? What harm would this do to Eclipse?
Doug, please see comment 4 for our position.
I guess my thought was that comment #10 and comment #12 and comment #14 seems to rebut comment #4 effectively. Not to mention, previously raised discussions about how much complexity this adds to the platform/ui component (i.e., supporting a complete legacy system, a complete new system, and somehow integrating them into a unified user experience).
I understand the burden that is for Platform/UI to handle (and expose) both content type and the legacy file name based editor associations. This has never been questioned. I also understand that providing what is requested in this PR would make that task much simpler. I just don't agree that pushing that stuff (which really does not concern any of the other clients) down to the content type infrastructure would be a good solution. If you imagine that content types were there since Eclipse 1.0, and that direct file x editor association had never been supported, other than for external editors (which may be able to manipulate files for which no content type exist), there would not be any scenarios to justify this.
This doesn't make any sense. What is the point of the content types system unless it's to support the UI? The UI team (or at least those of us on this CC list) is unanimously saying that the current content types system doesn't do what we need. Who is driving the requirements here? Content types are a tool. Please listen to the feedback of the people using that tool. As things stand now, we can't address important use cases. Please reopen and fix this PR.
"I just don't agree that pushing that stuff (which really does not concern any of the other clients) down to the content type infrastructure would be a good solution." What is it, exactly, that you're worried about pushing down? What we need is the ability to create, destroy, and manipulate content types programmatically. That seems to be a perfectly reasonable thing for the content type infrastructure to do.
Contributing a content type requires careful consideration, even developers have trouble doing it. Also, file name patterns do not provide enough input for creating content types. Content type providers can provide a content describer, which is a small object that helps the platform detecting whether a file belongs to a content type or not, and how to extract content type specific information. Users cannot provide that. And describer-less content types decrease the quality of content type detection. Moreover, content types affect several features in Eclipse, so users cannot easily figure out the implications of adding a new content type. Just checking if editor association works as expected is not enough. Content assist can be broken. Contentent sensitive contributions can be broken. But the main concern here is that these user-defined content types you would like to create are *not interesting/useful* to any content-type aware features in Eclipse other than editor association. If a feature knows how to deal with a kind of file, a content type would have been defined. The two scenarios not handled by this are legacy editor file name based associations and external program associations. After weighing in the pros and cons of significantly changing the content type infrastructure to handle these two scenarios, I think it would be better if we kept these idiossincrasies away and dealt with them where they belong.
Editor associations are the single most visible use of content types to end users (and probably the only one they will be aware of). IMHO, this makes it the most important use case. As you said: "these user-defined content types you would like to create are *not interesting/useful* to any content-type aware features in Eclipse other than editor association." and: "Content assist can be broken. Contentent sensitive contributions can be broken." The former contradicts the latter. Content assist and content sensitive contributions can't be broken by the addition of user-defined contributions that they don't use. You're right that describer-less content types would be useful for editor associations and little else... but editor associations are exactly what we're talking about.
Editor-content type associations are the most important use case, I don't deny that. But it is a use case that is (mostly) supported. What you request here is that: a) content type support be stretched so existing editor-file associations can be seamlessly migrated b) external programs can be based on content types. >Content assist and content sensitive >contributions can't be broken by the addition of >user-defined contributions that they don't use. To clarify my seemingly contradictory statements: user-added content types do not bring any value to any other feature in Eclipse but can break those features by polluting the content type space and potentially introducing content type detection issues due to conflicts.
editor association is maybe most visible, but I'm not sure that makes it most important. In my mind, having correct non-uniform encoding/decoding of files is the most important. [just to add my humble opinon]. I've only recently followed this dicussion, so don't understand all the issues, but will only add support to Rafeal's remarks that its hard for even plugin providers to get content type defintions correct ... I'm not sure we know enough to "allow users to do it" (in a safe way, disambiguating everything, making sure they knew what else they might be effecting, etc). The fact that there seems to be two opposing sides to this issue makes me think there must be another, better solution.
Hmm, if have the same problem. I'm building an eclipse independant api to access archive files. The api has its own detection facility for archiving. I'm implementing Eclipse Filesystem with that API to see the archive structure in the viewer. To enable eclipse filesystem and the editor i need to make contentypes for eclipse, but I already have it in the api. Now I need to build it twice, one for jarhive and now one for Eclipse. I would like to adapt the jarchive registry to fit in Eclipse. There are a lot of archive files and I do not like to do it al over again for Eclipse. Is there any possible way to fix this, and if you need help for that let me know, because I realy need it. Why not implement an extentionpoint for adapting registry support, therefore Eclipse is still in control about the entries it accepts Kind regards, Maarten Storm
Reopening: there is a strong demand for this feature, and there is still no acceptable workaround.
Rafael: are you still working on Eclipse? If not, we should probably punt this... :)
No, Kim, please go ahead and reassign as appropriate.
bug 37668 comment 17 describes the requirements for the content types system. bug 98223 describes how this could behave from an end-user perspective.
Correction: bug 98233 describes how this could behave from an end-user perspective.
Moving content type bugs to the resources component.
Mickael, I thought you might be interested in this bug since you're doing some work on content types.
Gerrit change https://git.eclipse.org/r/83666 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=05866463ef4920b75dfd7424a31644add49fbbf2
Please fix the API Tools errors.
Thanks for the note Markus. I'm a bit confused by the report ( http://download.eclipse.org/eclipse/downloads/drops4/I20161129-2330/apitools/analysis/html/org.eclipse.core.contenttype/report.html ). It says version should be bumped to 3.6.0, but the bundle version is already 3.6.0 as far as I could see... I'm probably failing at interpreting the report, can you please give some insights?
The report says "The *major* version should be incremented *in* version 3.6.0,". The major version is the first segment, i.e. the report suggests to update 3.6.0 to 4.0.0. Since the problems are only internal issues (@noimplement should have been added when API Tools were first enabled on the project), the right solution here is to add commented API Tools filters for the concrete issues (comment should refer to this bug). Don't add a filter for the suggested version change.
(In reply to Markus Keller from comment #37) > The report says "The *major* version should be incremented *in* version > 3.6.0,". > The major version is the first segment, i.e. the report suggests to update > 3.6.0 to 4.0.0. > > Since the problems are only internal issues (@noimplement should have been > added when API Tools were first enabled on the project), the right solution > here is to add commented API Tools filters for the concrete issues (comment > should refer to this bug). Don't add a filter for the suggested version > change. Thanks, I'll try that.
New Gerrit change created: https://git.eclipse.org/r/86147
Gerrit change https://git.eclipse.org/r/86147 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=e554bed6a462669e9251de90995993570a1a57ae
