Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] DetailsPaneMaxLengthDialog/DetailsPaneMaxLengthAction in platform.debug and dsf.debug

Actually, I'd rather go the other way and eliminate the dependency completely.  The number format detail pane was done in a hurry and it could be greatly simplified such that it wouldn't need to depend on debug platform internals. 

If you would like to, you could request to create a base class for a detail pane in platform.  If there's a sufficient value in such a base class we can add it as proper API.


On 10/26/2010 10:47 AM, kirk.beitz@xxxxxxxxx wrote:
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:

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 ++

_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx

Back to the top