Bugzilla – Full Text Bug Listing
| Summary: | [Viewers] FilteredTree job delay should be overridable | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Susan McCourt <susan> |
| Component: | UI | Assignee: | Susan McCourt <susan> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bokowski |
| Version: | 3.5 | ||
| Target Milestone: | 3.5 M4 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 244390 | ||
|
Description
Susan McCourt
Boris, I'm going to take the liberty of fixing this. There is already precedent in this class for allowing the subclasses to override the refresh job itself, so I don't see a problem with allowing them to override the hard-coded delay. I need this in order to move p2 to more standard usage of FilteredTree and fix bug 244390 Spec/implementation of new method:
/**
* Return the time delay that should be used when scheduling the
* filter refresh job. Subclasses may override.
*
* @return a time delay in milliseconds before the job should run
*
* @since 3.5
*/
protected long getRefreshJobDelay() {
return 200;
}
Fixed in HEAD >20081126 Just wanted to explain some rationale here for Boris and anyone else reading this. The downside of this method is that we are making it easy for subclasses to introduce subtle differences in response time that may take users by surprise. On the other hand, subclasses and clients tend to know the usage patterns of their tree - what kind and how much data is going in, and how much delay is needed. I also considered the fact that data binding already allows client configurable delays in DelayedObservableValue. That is why it seemed reasonable to me to make this configurable. It was also the last remaining reason for p2 to have to extend way more of FilteredTree than we would like to. verified on WinXP, I20081209-0100. p2 is using a slightly longer delay (400ms) |