| [cdt-dev] DetailsPaneMaxLengthDialog/DetailsPaneMaxLengthAction in platform.debug and dsf.debug |
| hello to all familiar with the VariablesView details-pane implementations ++ in edc, i'm trying to set the edc-based details pane code to make better use of the "Max Length" (and also "Word Wrap) by re-using existing classes where possible. the DetailsPaneMaxLengthAction class, the DetailsPaneMaxLengthDialog class which it invokes, classes are implemented in both: - org.eclipse.debug.internal.ui.actions.variables.details - org.eclipse.cdt.dsf.debug.internal.ui.viewmodel.detailsupport they are almost duplicates, except for the IDs passed to help and preference-store calls. (DetailsPaneWordWrapAction/DetailsPaneWordWrapDialog is similarly "duplicated" in both locations.) my assumption is that the reason that these are duplicates is due to API restriction on them being internal classes. currently, the only consumer of the first is org.eclipse.debug.internal.ui.views.variables.details.DefaultDetailPane, and the only consumer of the latter is org.eclipse.cdt.dsf.debug.internal.ui.viewmodel.numberformat.detail.NumberFormatDetailPane as it stands, NumberFormatDetailPane already depends upon other org.eclipse.debug.internal.ui code, so adding another exception to the internal API restriction wouldn't be without local precedent. might it thus make sense to eliminate the dsf versions of these actions & dialogs and have NumberFormatDetailPane depend upon the platform ui version? is there another reason to have these duplicates? ++ kirk beitz : nokia : austin + san diego : kirk.beitz@xxxxxxxxx ++ |