Community
Participate
Working Groups
Allow users to disable content types at a global level or at a project level. This would be interesting in the case we do not detect the right content type. See also bug 69640.
Content-type project specific, seems to be important for the CDT folks This is mark as enh. ... What would it take to make this a reality for 3.1 timeframe ?
I would have time to address the Core part of the problem by M6, but the UI folks are overwhelmed by the work they already have to do. The UI should be something in the form of a properties dialog page that would show only for projects. A simple list of content types with check boxes might be enough (a la Project References page). Would you be willing to provide a patch?
Below is an excerpt from CDT mailing list with Leo: > Will this enhancement be done in Eclipse 3.1? Will CDT drop the > per-project file extension associations if it is not? I would not like > to see the functionality dropped. Developers can find themselves > working with someone else's code where "strange" file extensions are > used, but not necessarily want these extensions to be valid in the > projects that they create. > > Regards, > Leo a scenario *.tcc is use by cygwin to say indicate a C++ template file and should be parse by the C++ source parser. The content-type per nature solves the problem for the ISV, so when they(ISV) ship with the CDT, there wizards will add a nature to the project so new content-types will be available to there specific projects. But for the open-source users, working on say Linux, needing to add an extension for QT or for its own libs(*.t for template), it is not possible without affecting things globally. I think, with the coming of content-type/natures, I can argue with with the CDT folks on the need to totally embrace the IContentTypeManager framework(so we can drop the old Resolver Model), but having project specific will probably help.
(In reply to comment #2) > I would have time to address the Core part of the problem by M6, but the UI > folks are overwhelmed by the work they already have to do. The UI should be > something in the form of a properties dialog page that would show only for > projects. A simple list of content types with check boxes might be enough (a la > Project References page). Would you be willing to provide a patch? Questions: - What will be the new API to add/get/remove content-type on the IContentTypeManager ? - You guys have already have an API preference page, as an example: Type UI plug-in</a>. A simple plug-in that contributes a preference page for managing content type file associations, useful for testing. downloads/examples/contenttype/com.examples.contenttype.ui_1.0.0.zip making this a Property page would that be a good start ? I'll be happy to modify that example or contribute back a complete new UI. Are the sources somewhere for that example ?
So far we are not planning allowing programmatic addition/removal of content types. The idea here is just to mark selected content types at the platform level/project level, so others are favoured to the detriment of the marked ones (or the other way around). Alain, let's wait until next week when the Platform/UI guys are back from EclipseCon to discuss about the property page since they may have their specific requirements on how this should be achieved.
(In reply to comment #5) ... > > Alain, let's wait until next week when the Platform/UI guys are back from > EclipseCon to discuss about the property page since they may have their specific > requirements on how this should be achieved. Any news on this ? from the UI folks
UI has added a content-type preference page (Under Editors) that is in head and will be in next weeks integration build but havn't had time to investigate this issue. We would be happy to try and support any mechanism that core could offer to make this easier, but we don't have time to roll this behaviour ourselves for our editor resolution strategy.
What was intended here has never been actually asked by anybody. Bug 87447 provides what is needed by CDT (see comment 3). To avoid adding gratuitous complexity to the content type story, we are going to postpone this feature to a future release.
[LATER->WONTFIX] The "LATER" bugzilla resolution is being removed so reopening to mark as WONTFIX.
