Summary: | [Viewers] Provide Way to Get Viewer From Control | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Adam Cabler <acabler> |
Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | mistria, tom.schindl |
Version: | 3.3 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Adam Cabler
2007-05-30 14:50:23 EDT
I'm not keen on doing this. If you try to access the viewer for a control that you created, you can always store the viewer using setData() yourself. However, if you try to get the viewer for a tree that you don't own, like in the case of the Properties view, chances are high that the code for the Properties view assumes that no one else has access to the tree viewer. Basically, I am not convinced that an API that allows you to reach into other components' internals more easily is a good thing. Well, I'm not really against something like this. Let's leave this open and think about it later on. Is see the problem that people work-around this limitation using things that will break things miserably because they start accessing Viewer-Wrapped controls at the SWT-Level which will lead into many many problems. I understand the issues with doing something like this. For us, it isn't an issue since we are providing the workbench. I can see it causing problems in a mixed plugin environment. However, there are lots of things plugin authors have access to that can break the workbench for other plugins. In this case, I had access to the tree control, so I could cause as much harm as with the viewer. Bottom line for me is that it was way harder than it needed to be to simply add expand/collapse actions to the prop view. Anyway, thanks for the consideration. adam Hitesh is now responsible for watching bugs in the [Viewers] component area. |