Bugzilla – Full Text Bug Listing
| Summary: | [Field Assist] - secondary popup should update on same delay as its invocation delay | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Susan McCourt <susan> |
| Component: | UI | Assignee: | Susan McCourt <susan> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, markus.kell.r |
| Version: | 3.2 | ||
| Target Milestone: | 3.2 M6 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 120237 | ||
|
Description
Susan McCourt
investigate for 3.2. Not a stopper according to Dani. I'm not convinced that this is a problem. Are there bug reports you can point to where users complained about the secondary info updating too quickly? I assume you went to the effort of implementing the secondary controller due to user feedback... I would just like to understand better why this is a problem, as it seems simplest to just update when the selection changes. >Are there bug reports you can point
>to where users complained about the secondary info updating too quickly?
Well not for the Find/Replace but look for example at the code assist (or an upcoming field assist) where Javadoc is shown in the hover. Sometimes this is extracted from a Web URL (yes it is). This would make up/down navigation in the field assistant very hard. In my opinion it is also bad UI style to update that window while moving up/down. Look for example at the Java Outline view: we don't immediately select the selected method in the Java editor when moving up/down but wait a little. Otherwise the UI would be sloppy.
If you still need bug numbers I can dig out some regarding our standard code assist.
This is definitely necessary if field assist is to be used in situation where the additional info is nontrivial to compute (e.g. content assist for Java types). Furthermore, the immediate updating is quite distracting. The user cannot possibly read anything in the secondary popup while scrolling through the proposals. Therefore, the flashing in that area is of no use - the only interesting change is the selection in the list, so screenredraws should be limited to that area. I experienced the javadoc URL retrieval problem first hand, so I can relate to the performance issue. For some reason, in my mind a field-based assistant is more "lightweight" than full blown code assist, but I'm coming to realize that this is not the case. I have a simple implementation that updates the secondary popup using the same delay as the invocation of the popup. This gives a nice delay, but a difference is that occasional updates can still occur while arrowing down, so it may still be too distracting according to your comments. What do you think? Released the simple delay >20060317. Since this was not a stopper, I'm hoping it's good enough for now, but will not close this bug until getting your feedback. I'm not trying to be difficult, just trying not to blindly copy implementations without understanding the reasons behind them, since I will have to maintain it. I think this will work. An easier solution for you might be to simply use a post-selection-listener instead of manually managing the delay. Note that our implementation has bug 129168. The current implementation is using a raw SWT table, not a viewer, so post selection is not an option. If there comes a time to use a viewer for other reasons, I can look at getting rid of the delay code. Marking this one fixed. (side note: this implementation also computes the description in the UI thread and similarly does not spec when it may be called...) correcting milestone. this bug was fixed and verified for M6 |