Bugzilla – Full Text Bug Listing
| Summary: | [Decorators] Open Resource dialog should support decorators | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Markus Keller <markus.kell.r> | ||||||||||
| Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> | ||||||||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||||||||
| Severity: | enhancement | ||||||||||||
| Priority: | P3 | CC: | bokowski, daniel_megert, mik.kersten, steffen.pingel, wmitsuda | ||||||||||
| Version: | 3.3 | ||||||||||||
| Target Milestone: | --- | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Markus Keller
Created attachment 59877 [details]
Proposition of changes inside patch
Krzysztof this patch is out of date Created attachment 62480 [details]
Fix patch refreshed to head
In this patch it looks like you are only updating visible entries? What happens if someone scrolls? Will they get old data? You likely want a simpler solution like only calling refresh on those items that you have added. Created attachment 63110 [details]
Patch from K.
I am wondering why you need to look these items up using doTestItem? When you refresh the list you will know the existing items before you refresh. When you call your refresh in you will have the old list and the new list. You could just iterate through the two and check. Having said that this really shouldn't be flashing the decorators if the content hasn't changed - have you checked if the viewer is forcing a redraw when it doesn't need to? Created attachment 64188 [details]
Proposition of changes
I remove using of doTestItem from muy solution. I store next to last result of filtering and compare it with last result. Depend on it i remove, add or replace emelents in TableViever.
Kryzstof I am still not clear why we need to do anything special - you should get these updates without flashing from the viewers with no extra work. If the viewers are refreshing entries that they do not need to then there is a bug with them. You should not cache your old values. This issue is harder than it looks at first. We should try and do something about it but we can`t promise it right away. As follow up from bug 130340 (thanks for the pointer Markus) I'd like to better understand this problem, because we have seen it in a few places (e.g. Mylyn's Task List still has it). My expectation is along these lines: 1) Element A has decoration x. The data for A has changed so that it no longer needs this decoration. 2) A gets refreshed. The decoration is still there after that refresh. 3) Once the decorator job has had a chance to run, the x disappears. Unless we are making some other mistake, which is entirely possible, it appears to me that image decorations do not stick as per (2), and instead are always removed as a result of the refresh, and then put back with (3). So with a viewer that has a lot of decorations and requires periodic full refresh, this or a related problem is causing decoration blinking. Mik you are looking at something different. The flashing is usually caused by a refresh that clears a decorator and a second refresh that restores it. Are you changing any state in that time? We don't update until decoration is finished. The other issue is if there are any full decorators. As we can't batch then up like the lightweight decorators some flash can occur. *** Bug 226982 has been marked as a duplicate of this bug. *** The fix for bug 227982 has removed the decorations and the flashing. This bug can either be closed or transformed into a request (>3.4) to support decorators again (without flashing). I suggest we close this as wontfix. The Open Type dialog doesn't show decorators either. Haven't heard any arguments to keep decorators in the dialog. Closing as wontfix. |