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?
