Community
Participate
Working Groups
Build ID: I20061102-1715 Steps To Reproduce: 1. Dock the Problems view into the fast view toolbar 2. Create an error/warning in a Java file and save it Note that the icon for the problems view doesn't change, even though the number of problems has changed. It would be handy if the icon for the problems view was decorated when new problems appear.
Hmmm, we were talking about something vaguely along these lines yesterday. The actual discussion was about when/if we should 'bold' the tab text for a view that isn't fast but I can see the symmetry of adding a decoration to a fast view's icon under the same circumstances (i.e. bold text in the presentation == decorated fast view icon). I'll bring it up with the design group. Note that we haven't yet decided whether or not the bold'ing idea makes sense yet...
This is a generic problem (ie. not FVB-related) that is covered by other defects.
What's an FVB? I wasn't able to find any bugs dealing with the Problem view's lack of useful fastview icon. Which bugs are they? I wouldn't call this a generic problem - it deals specifically with the Problems view.
We've been reviewing various scenarios for handling changes (bolding text...) but none of these has worked out. The Tooltip change is the best we can do until a comprehansive approach can be defined...
Reopening for investigation.
I've committed a prototype to HEAD. Available in builds >= N20101015-2000. Interested parties, please give it a try. For now, the icons are hand made and of course we would have to request proper icons from the graphic designer. For that, I'd also like to hear whether we must stick to the current icon (i.e. just decorate the existing one somehow) or whether we also allow a new design.
Created attachment 180942 [details] Patch with icons
I like to work with this feature! You can even have multiple Problems view (fast view) icons to track different states, e.g. whole workspace, project and containing folder of the selection at the same time. There is one little issue, which is nothing new and caused by the Eclipse architecture: like the tool tip, the icon is also not showing the real status until the view gets creted. We could 1) live with that limitation 2) force the view creation 3) like 2) but add a preference (load by default) 4) like 2) but add a preference (don't load by default) 5) add background job to update the icon ==> this would require new API and probably not safe us much compared to simply creating the view, as similar code would be needed to know the view inputs and filters in order to update the view icon. My preference is 4. This won't add any performance overhead to current clients and since we will advertise the new feature in the N&N, we can also mention the preference there.
(In reply to comment #1) > See related Bug 282585 Comment 3 Bug 80310, Bug 69621 and Bug 282585
On a side note, I have even wondered if we should defer updating the View's UI to a point when it is actually visible. That way you could avoid transient UI updates and save CPU cycles. That is, if the end result of the build is all you are interested in (view hidden). The tooltip can continue updating, and view's UI updates normally when visible.
(In reply to comment #11) > On a side note, I have even wondered if we should defer updating the View's UI > to a point when it is actually visible. That way you could avoid transient UI > updates and save CPU cycles. That is, if the end result of the build is all you > are interested in (view hidden). The tooltip can continue updating, and view's > UI updates normally when visible. Agreed, but that's interesting independent of this feature. Please file a new bug report for that.
Remaining issues: - get official icons (bug 329001) - make sure the state is correct after workbench start (bug 329002)
This is broken in 4.2.
Dani, could you open a new defect to track the work that we need to do in 4.2 ?
(In reply to comment #15) > Dani, could you open a new defect to track the work that we need to do in 4.2 ? I suspect it's the same reason as reported in bug 318866, which is one of those bugs that don't make me use 4.x.
*** Bug 208254 has been marked as a duplicate of this bug. ***
