Community
Participate
Working Groups
This behaviour is a side effect of the fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=107121. In order to improve performance when using large workspaces, the platform uses a "guessing" algorithm for icons. This algorithm uses the "general is better" policy for choosing between content types in a hierarchy. Thus it picks the icon of the editor associated with the more generic content type instead of the more specific one. See for example https://bugs.eclipse.org/bugs/show_bug.cgi?id=139756 A potential solution is proposed here https://bugs.eclipse.org/bugs/show_bug.cgi?id=107121#c12 but it appears it did not get implemented yet.
*** Bug 139756 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 8232 ***
Tod, I don't really see how this bug is a duplicate of 8232. Can you please provide more details?
Actually you are right Valentin - I thought this was the same as the external icon issue
I think this is a fairly serious problem. The way things are today we have no way of displaying the proper icons for various artifacts such as XML Schema and WSDL files (we get the vanilla XML icon if we like it or not). Any thoughts on how this could be fixed? If there's some issue with content type checking then perhaps our editor could also specify a file extension in the plugin.xml and the proper icon would get used at least for files that matched the extension?
Any update on this issue? We feel this is a major issue that needs addressing for 3.2.1.
I don't believe this can be properly addressed in a point release. As I outlined in the comment referenced, this is a very major change that will likely require new API or massive refactoring at the very least. I don't believe there is any solution or workaround that I can suggest for 3.2.1.
That's really bad news. Kim can you provide a summary to explain how we ever got ourselves into this predicament where something as fundamental as displaying an icon for a file doesn't work properly? Is this a case of the platform and adopters moving onto a 'content type' approach too quickly (before the infrastucture is ready)?
Well, it was working "correctly" for a time. When we are passed a file to obtain an icon for we would check the content type of the file and do lookup based on that. This is great... provided you implement an efficient content type checker and you dont have thousands of files to determine icons for. It was pointed out to us that large directories were taking FOREVER to render because of the content type lookups. We had a blocker PR from an IBM team that said we needed to get this fixed for a release and it happened so late in the cycle that the only solution was not to resolve the icon and fall back on the default. We were between a rock and a hard place and we felt the solution that didn't look like a deadlock was the appropriate one. It's too big a problem for a point release and for almost the entirety of 3.2 I was on another project - there was no one to fix it. It's unfortunate - by our estimation the content type support was ready for primetime right up until the speed defect was brought to our attention by which time it was too late to back out of it.
I second Craig's comment that it's really bad news that this can't be fixed in 3.2.1. From a user perspective this is a regression from 3.1 that may affect their productivity. (Those nice icons are there to help differentiate resources, right?)
Given the potential risk to performance this will be deferred until 3.3.
*** Bug 157910 has been marked as a duplicate of this bug. ***
Any update or ETA? This is a very visible problem that impacts the usability and look and feel of adopter products. Is there something fundamentally broken with respect to our support for content type? Do we need to rethink this mechanism. IMHO the akward integration with the file association preferences and content types(and associated usability issues) along with this icon association issue leaves me wondering if the concept of content type is more trouble than it's worth. Any thoughts on the usefulness/effectiveness of this bit of machinery?
There was no time for this in 3.3. :( Given the scope and underlying reasons regarding the difficulty in implementing this change I would hesitate to commit to this in the 3.X stream. Editor management is, however, a prime candidate for improvements in the 4.0 stream.
Marking for investigation in 3.4. I cannot promise anything at this point other than that I will look at this soon.
In bug 194935 I described a scenario that appears related. In there I explore the potential cause and a solution that may apply to both bugs.
I filed bug 198208 how the current implementation of the XMLRootElementContentDescriber is broken (when using that class, the content type is not determined by the contents of the file if a filename or file extension is specified). I think that the final resolution of that bug depends on the correct working of icons in editors.
(In reply to comment #17) > I think that the final resolution of that bug depends > on the correct working of icons in editors. Ooops, it's the other way around of course. Correct working of icons in the navigator depends on correct resolution of content types.
*** Bug 110961 has been marked as a duplicate of this bug. ***
If we could not get all views to display the most specific icons, which ones were most important to get right? Is it just the Project Explorer? The reason for this question is because I would like to avoid having to compute the correct icons for all files under a certain parent (there might be hundreds or potentially thousands). Using 1600x1200, my vertically-oriented navigator shows 60 items, which would be a nice upper bound for how many content type lookups we cause. To find out which items are currently visible, the underlying tree would have to be SWT.VIRTUAL or it would have to make use of owner draw. The latter seems easier to implement. For example, JDT's package explorer already uses owner draw as of 3.4.
Created attachment 93205 [details] patch This patch uses the decorators mechanism for computing a more accurate icon in the background. If possible, I would like to get feedback as soon as possible how this works for use cases that failed before (i.e. hundreds of html or xml files in one folder).
To apply the patch, you need org.eclipse.jface, org.eclipse.ui, org.eclipse.ui.ide, and org.eclipse.ui.workbench in your workspace.
After sleeping it over, I released this change to HEAD. I believe it is at least part of the solution of getting accurate file icons. If this patch causes performance problems, we still have a number of possible optimizations that can be applied. I am still interested in feedback, in particular with regards to performance.
Looks good to me. If we dont already have this optimization in place, it might be good for decorators in general, but do we delay decorating non-visible icons?
(In reply to comment #24) > If we dont already have this optimization in place, it might be good for > decorators in general, but do we delay decorating non-visible icons? As far as I can tell, we don't do anything like this yet. The most accurate solution for delaying would be to use the owner draw events (or SWT.VIRTUAL).
In a way we do - we only decorate what you ask for. If you don'task for non visible icons we won't decorate them.
Boris, thank you for fixing this. I have done some limited testing using an older WTP driver (with a pre P2-ed platform, http://build.eclipse.org/webtools/committers/wtp-R3.0-I/20080324171756/I-I20080324171756-20080324171756/) and pulling in the code from HEAD into my workspace. At a superficial look, the fix appears to be working correctly from a functional point of view. To test, I created the sample WTP project Editing and Validating XML files and inspected the WSDL and XSD resources and verified that the actual WSDL and XSD icons are used instead of the generic XML icon. I have also used the zip with 2500 HTML files attached to bug 107121. I renamed all the files from *.htmltestonly to *.html and placed them into a folder. And lastly I used a project with lots of XSD files. Overall, on my dual core notebook, performance was pretty good for the project with lots of XSD files and decent for the one with lots of HTML files. I take it that the HTML content type descriptor is a bit slower. It seems to read in quite a bit of the file's content to infer the file's encoding. I also used the "show system jobs" feature of the progress view and confirmed that the content type decorator job was running. Sometimes the job seemed to take quite some time and wait more toward the end. I would think the best way to improve performance would be to speed up the processing that takes place in the content type descriptors but only profiling will tell exactly where the time is being spent. As you suggested, periodic updates to show the computed icons for the visible resources (typically under 100 depending on the resolution) would improve the perceived responsiveness. We hope to do more testing once the P2 dust settles and we can use a more recent WTP driver. I have also sent a note to wtp-dev to make the committers and adopters aware of the change. Perhaps a similar note is in order for some of the platform dev or cross-project devs lists?
Verified in I20080327-2251
Just FYI - we are currently discussing how important it is to update file icons when the file contents change. See bug 223976 if you want to participate in that discussion.
