| Summary: | Customize images for Navigator Content | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Pradyut Sarma <pradyutksarma> | ||||
| Component: | Client | Assignee: | Project Inbox <orion.client-inbox> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | mamacdon, simon_kaegi | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Pradyut Sarma
Having the file server define the icons used by a particular client is a bit strange. We generally don't want client implementation details in the server or file system implementation code. Another approach is that file icons come from editor associations (use the editor's icon for files associated with that editor). This is roughly what Eclipse desktop does. Related to bug 349802. (In reply to comment #0) > I am not sure whether it is enough to just accept the image URI for a > file/folder or an entire CSS class to describe the contributed content. General comment: we should stick to CSS classes rather than image URLs. CSS allows more control, and it's required for common web development tricks like 'sprites' (combining images into 1 large grid to reduce HTTP overhead). We don't currently have a mechanism for plugins to contribute CSS (see Bug 347493) Hey John, I agree to the technical POV that the client and server implementations shouldn't be mixed up. But I still have a couple of points to support my stand. The idea of using the editor icon for the file associated with it works in case of a one-to-one association of a file type with an editor but that would rarely be the case. That is because, an editor may be used by more than one file type to render its details. In such a case, it is most important to safeguard the semantics of the object that is displayed in the Navigator even though the editor icon may not always do that. An example of such a case is attached with this message where an XML editor is used to render a WSDL whereas one look in the Navigator makes one understand that the object in the tree is a WSDL. Even in case of Eclipse-In-Desktop, the navigator icons come from a Label provider whereas the editor icon from the editor contribution/extension point. Just some thoughts ;) Thanks and Regards, Pradyut. Created attachment 198851 [details]
File Semantics
(In reply to comment #3) > editor icon may not always do that. An example of such a case is attached with > this message where an XML editor is used to render a WSDL whereas one look in > the Navigator makes one understand that the object in the tree is a WSDL. Even > in case of Eclipse-In-Desktop, the navigator icons come from a Label provider > whereas the editor icon from the editor contribution/extension point. I think you will find that the Navigator label in Eclipse comes from the editor association. If you change the default editor for a WSDL file to the XML editor, then I believe that icon in the Navigator will change. Hey John, You are right about the WSDL file association. In case of changing the default editor to XML for a WSDL, the Navigator icon also changes. I tried to do the same for a .java file by changing the default editor for a java file to a text editor. But the Navigator icon still depicts a java CLASS and not a java FILE, even though double clicking on the java class opens up the content in the text editor. Thanks and Regards, Pradyut. (In reply to comment #5) > I think you will find that the Navigator label in Eclipse comes from the editor > association. If you change the default editor for a WSDL file to the XML > editor, then I believe that icon in the Navigator will change. Pradyut, this request is now implemented via bug 366265. Since you opened this bug, we introduced a content type definition mechanism, and it is now possible to define content types as well as specify an icon for them. *** This bug has been marked as a duplicate of bug 366265 *** |