Community
Participate
Working Groups
With the introduction of editor content-type bindings the existing File Association preference page is misleading. This page should reflect bindings by content-type as well as traditional filename assocations. I am soliciting for suggestions as to how this should appear to the user.
Maybe the filename association became redundant. In versions prior 3.1M7 one had only to add a new file association to use a different editor. Right now this seems to have no effect until one creates a new content type. See bug 95317.
*** Bug 95317 has been marked as a duplicate of this bug. ***
Kim, as a WTP client commented in bug 95227, one important area to handle better is the meaning/display of "default". (Sorry, I don't have concrete suggestion, just didn't want that aspect to get lost.)
This bug may not be addressed for 3.1 in liu of bug 91966. Interested parties should CC themselves to that bug as well if they havn't already.
Created attachment 21379 [details] Work in progress A patch based on suggestions made by Amu Wu in Bug 91966. Adds the editors for content types to the editor list in the preference page but makes them unremovable.
Patch submitted. I would appreciate it if any interested parties could give it the beats whenever a good build is produced.
Looked at it in N20050519-0010: It's good that the editor which is bound via content type can't be removed from the 'File Associations' page anymore. I would show the content type on the ''File Associations' page as well, either in the list (which is probably harder and more work): *.xml (Ant Buildfile) or below in the 'Assiciated editors' area: Ant Editor (locked by Ant Buildfile) or: Ant Editor (locked by Ant Buildfile content type)
Your second option is doable. I will investigate.
I've created bug 96413 to track that particular defect. I am going to mark this bug as deferred for 3.1. Any new tweaks against the changes I've made should be entered as new PRs if they can't wait for 3.2.
*** Bug 98233 has been marked as a duplicate of this bug. ***
From bug 98233: The content types page looks potentially very powerful, due to its ability to generalize similar file formats. For example, I'd expect to be able to register a new editor (or change the default editor) for all XML files or all text files (which could potentially eliminate a lot of tedium in listing every file extension that is really an XML file and registering it with my favorite XML editor). As an experiment, I tried to change the default editor for the "text" content type. Seeing the message on the top of the page, I went to the "File Associations" page. However, the file associations page can only create associations between file extensions and editors, which is not what I want (I want an association between a content type and an editor). Without the ability to create an association between a content type and an editor, most of the potential power of content types seems to disappear. Here's how I'd expect it to work: - There is only a "File Associations" page (no separate content types page). - The upper pane shows the tree of content types - not file extensions. - The bottom pane shows associated editors (as it does now). - There is a new "Properties..." button (or Edit...) that allows the user to configure the content type (edits the associated file extensions and default character set which are currently set in the "content types" page. Should also allow an icon to be specified for the content type). Even if it doesn't work exactly as I describe, the important parts of this enhancement are: 1. editor associations should be based on content types, not file extensions 2. the associations should be done using a single preference page, not two 3. the properties of a content type (file extensions, char set, etc.) should be edited in a properties dialog for the content type.
See my comments in bug 57908. Content types and file associations should NOT be two different types of thing. A file association should be just another content type, except that it is recognized purely by filename. Users should be able to create new content types through the UI and change which editors are registered with each type (bug 57908 has plenty of use cases).
I think the editor associations preference page should be made more content type aware, but I don't think editor associations and content type preference pages should be merged. My suggestions are: invert the order the file types and editors list appear (editors should appear first), and allow users to associate either content types or file types the selected editor. 1) change the editor associations preference page to allow users to associate file types to editors, not associate editors to file types. What I mean is that the editors list should appear first. Editors are the central concept here. 2) allow associating either content types or "file types" (this name could be changed). I will attach a sketch to explain better what I mean.
Created attachment 24240 [details] sketch for the proposed editor association page layout
Rafael's sketch looks good to me. The confusing part will be UI for setting the default editor for a content type and/or file extension. I suppose you could have a "Make this editor the default for this content type/file extension" button down in the Associated to area. You'd have to come up with a shorter button name though.
re: comment 13 This is backwards. The upper "master" pane should be a tree of content types. The lower "detail" pane should be a list of editors. Problems with doing it as suggested in comment 13: 1. You open an editor by clicking on the file, then choosing the editor you want - not the other way around. The workflow for editing the associations should match the workflow for using them. 2. If a user wants to change the options that show up when they right-click on an XML file, then (with the proposed mock-up), they would have to click on every single editor and remember which ones were associated with *.XML files. Changing the default would be worse. If they want to set an editor as the default for XML files, they would be unable to see what the old default is (or browse the list of other possibilities). 3. This is the opposite of every other app that supports editor associations. Look at the application associations in Windows XP, KDE, OS/2, Firefox, or Gnome. All of them show you a list of file types and then let you edit the list of apps to associate with those file types. None of them do it the other way around. This means that, no matter what environment the user is familiar with, they will expect it to work as suggested in comment 11 - not as suggested in comment 13.
(In reply to comment #16) > re: comment 13 > > This is backwards. Agreed.
Any plans to put this into 3.4. This is a very confusing issue for beginners.
*** Bug 149911 has been marked as a duplicate of this bug. ***
I cannot guarantee it, but I will try to do something about this in 3.4. Dani, do you agree that the way to go is what Kim described in comment #11, taking into account Stefan's comments (comment #13)?
>do you agree that the way to go is what Kim described in comment #11, taking >into account Stefan's comments (comment #13)? I lean towards Rafael's comments i.e. do not merge 'Content Types' and 'File Associations' as there are many clients that do care about content types but have nothing to do with editors (e.g. headless compiler, code generators, etc.). An interesting problem will be to deal with (new) extensions that are already covered by a content type (e.g. '*.java')? The 'Content Types' page should allow users to add new content types.
> as there are many clients that do care about content types but have nothing > to do with editors Nothing should prevent such clients from supplying their own preference page, as long as there is powerful API for creating and manipulating content types. As long as the preference page is shipped as part of the IDE and not part of the RCP offering, the editor-specific page shouldn't interfere with such clients. However the Eclipse IDE is a product that _does_ use editors heavily, so it should be okay for its preference page to make reference to editors.
Mass update - removing 3.4 target. This was one of the bugs I marked for investigation (and potential fixing) in 3.4 but I ran out of time. Please ping on the bug if fixing it would be really important for 3.4, and does not require API changes or feature work.
Remy is now responsible for watching the [EditorMgmt] component area.
With the introduction of Generic Editor (bug 497871) and ability to manually define content-types (bug 500892), this seems to be a bug worth a shot for M7. I cannot really commit to work on it yet, but it's definitely under my radar. Any help would be welcome though, don't wait for me if you're ready to work on it!
New Gerrit change created: https://git.eclipse.org/r/101091
(In reply to Stefan Xenos from comment #12) > Content types and file associations should NOT be two different types of > thing. > A file association should be just another content type, except that it is > recognized purely by filename. I fully agree with this. We now have users able to create content-types. As soon as we provide ability for user to associate them with editors (proposed Gerrit), then we can progressively deprecate the File/Editors association UI and APIs: 1. First, make the File/Editors association be stored as content-type/editors association: for each association, we create a content-type (with id conforming to a pattern or with a specific parent content-type to easily recognize it) 2. Then we can deprecate the extension points and APIs for file-association and redirect to content-types instead 3. Then we can deprecate the File/Editors assication preference page with a warning message or something like this.
Removing target as actual increments will be tracked in distinct issues (marked as "depends on")
As all pre-requisites are removed and since content-type preference page now offers all the customatization offered by the File Association preference page, I think it's worth considering a plan to deprecate/retire the File Associations page and code. In a first time, I think we can simply put a warning icon on the page at the top, beside the link redirecting to Content-Types page, and add a note about it being deprecated. We can also start deprecating all code related to FileAssociation (UI and model) and comment it with better way to cover the user-stories with content-types. Would there be any objection against moving forward with such deprecation?
(In reply to Mickael Istria from comment #29) > As all pre-requisites are removed and since content-type preference page now > offers all the customatization offered by the File Association preference > page, I think it's worth considering a plan to deprecate/retire the File > Associations page and code. > > In a first time, I think we can simply put a warning icon on the page at the > top, beside the link redirecting to Content-Types page, and add a note about > it being deprecated. > We can also start deprecating all code related to FileAssociation (UI and > model) and comment it with better way to cover the user-stories with > content-types. > > Would there be any objection against moving forward with such deprecation? Anyone?
(In reply to Mickael Istria from comment #30) > (In reply to Mickael Istria from comment #29) > > As all pre-requisites are removed and since content-type preference page now > > offers all the customatization offered by the File Association preference > > page, I think it's worth considering a plan to deprecate/retire the File > > Associations page and code. > > > > In a first time, I think we can simply put a warning icon on the page at the > > top, beside the link redirecting to Content-Types page, and add a note about > > it being deprecated. > > We can also start deprecating all code related to FileAssociation (UI and > > model) and comment it with better way to cover the user-stories with > > content-types. > > > > Would there be any objection against moving forward with such deprecation? > > Anyone? We need to differentiate between the UI and what clients can contribute (via plugin.xml). In a first step I would try to get rid fo the UI. We could add a content type that can hold the file associations. Here some possible names: Default File Associations None Undefined
> Anyone? Sorry for the late reply.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
