Bugzilla – Full Text Bug Listing
| Summary: | [Viewers] Public access for ListDialogField & IListAdapter ... | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Vikas Trivedi <vtrivedi> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P5 | CC: | bokowski, martinae, Mike_Wilson |
| Version: | 3.1.1 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
|
Description
Vikas Trivedi
JDT UI can't provide these API, they would belong to platform.ui. ListDialogField is a component that contains a list with buttons on the right and helps layouting, enablement, selection handling, up/down, add/remove default implementations and a simple add/remove/replaceElement API. There's also the CheckedListDialogField and the TreeListDialogField along the same line. All these components are not in the shape of being taken down without changes, but, IMO, contain lot's of code and bug fixes that clients should not have to rebuild their own. Not sure if these are better left under Viewers or Preferences. Passing to Boris to determine. (In reply to comment #1) > All these components are not in the shape of being taken down without changes, > but, IMO, contain lot's of code and bug fixes that clients should not have to > rebuild their own. I had a look at the classes, and it does not seem trivial to move the code down. Real work is needed before we can put this into the platform. For one, API documentation for clients is missing, and the API does not seem to be minimal. Furthermore, the class makes a number of assumptions about its context that would need to be looked at (e.g., can only be used within a GridLayout). Finally, it seems that if we decided to move ListDialogField into the platform, it should be accompanied by other subclasses of DialogField that are generally useful rather than having just one helper class for this particular case. Currently, we don't have the resources to do this work but would be willing to accept a patch. To get rid of the references to internal classes, you could copy the code into your plug-in. Is this not an option? Mike - this is an issue to be discussed between Vikas and UI team. There are currently no plans to do this but we would be happy to look at a patch Hitesh is now responsible for watching bugs in the [Viewers] component area. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |