Bugzilla – Full Text Bug Listing
| Summary: | IViewerUpdate should have a method to return viewer input. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Pawel Piech <pawel.1.piech> | ||||
| Component: | Debug | Assignee: | Curtis Windatt <curtis.windatt.public> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | darin.eclipse | ||||
| Version: | 3.4 | ||||||
| Target Milestone: | 3.4 M4 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 202680 | ||||||
| Attachments: |
|
||||||
Just curious... what is the use case for needing the viewer input? Note: we added a new udpate request in 3.4 for computing a viewer input asynchronously. For example, the variables/register views use a ViweerInputService to determine a viewer input. This new viewer request (IViewerInputUpdate) already has the method #get/setViewerInput(...), which will be confusing with the proposed patch. The spec for the methods is in conflict as the existing #getViewerInput() returns the newly computed viewer input, where as the proposed patch specs it as the current viewer input. I'm familiar with the IViewerInputUpdate but the conflict you mentioned didn't even cross my mind...
Our specific use case is in implementing the update modes ("manual", "on BP hit", etc.) for the debugger views. This implementation uses a cache which keys data using the element path from the update. However, the element path does not contain the viewer root and in some cases the keys for different elements (e.g. same breakpoint group from different stack frames) would map to the same data.
I've also ran into this problem in other places, but I was able to work around the problem by determining the input element from the model proxy factory. But the update cache is more generic and it doesn't have direct access to the model proxy data. So I thought that this is an omission that should be addressed directly in the viewer.
Would it be possible to change the IViewerInputUpdate method names to avoid the conflict. A more descriptive names would be get/setViewerInputProxy().
Is it likely that this bug will be addressed in 3.4? If not, I will try to create a workaround. Thanks -Pawel I think we can do this for 3.4 Awesome :-) Fixed. I renamed the conflicting methods on IViewerInputUpdate to get/setInputElement, and added getViewerInput() to IViewerUpdate. The register group proxy lies a little bit on the implementation side (which keeps the viewer stable across different frames). It claims the viewer input is the frame that the proxy is created on... which is what it wants the content provider to believe. Please verify, Curtis. Verified. Many thanks! -Pawel |
Created attachment 77902 [details] Patch adding the IViewerUpdate.getViewerInput() method (loc=39). Currently IViewerUpdate has two methods to access context of the update operation: getElementPath() and getElement(). When the request is made for a root element, getElementPath() returns an empty path and getElement() returns the viewer input. However when a request is made for non-root element, the viewer input is not accessible. Some viewer updates made on non-root elements may require access to the root element in order to complete properly, so this element should be added to the base update, especially that it is already available when the updates are created.