I applied patches for two of the minor
and we'll use this as a guide to tackle the others that are more involed.
>  _expression_ view actions use getAdapter() to work with non-
> standard debug models
> This bug is already being considered for 3.4 pending IP review.
> Fixing this bug would complete making the Expressions view agnostic
> of the debug model being used.
We'll fix this in 3.4 pending IP approval.
>  Extend PresentationContext to save and restore properties.
> This is a minor but a very useful feature. Currently, DSF actions
> which need to store settings about a given view are not persisted.
> We could invent an independent storage mechanism for these settings
> but it would be partly redundant and more complicated than the
> solution proposed in this bug. The patch itself is actually
> straightforward and it includes a unit test.
Will consider for 3.4.
>  VariablesView should use the ISelection object as viewer
> This is also a minor change, which would make the flexible hierarchy
> views even more flexible. It modifies the viewer input provider
> framework which was introduced in 3.4, so I think it would be nice
> if this feature request was considered before the viewer input
> provider makes it to a release. DSF probably would not take
> advantage of this feature in Ganymede, but it would definitely use
> it in the future.
Please see question on bug.
>  Top index not maintained properly in variables / registers
> The patch in this bug is a complex solution to a complex problem.
> I've spent about a week and a half developing and testing this patch
> so I'd love to see it included in 3.4. Specifically, the patch
> addresses a number of race conditions present when saving and
> restoring the state of the views. These race conditions are
> dependent on the frequency of changes in the viewer input and the
> amount of state information that needs to be persisted. The
> proposed solution adds logic to deal with partially-restored viewer
> states and works even when stepping code, or changing selection in
> Debug view very rapidly.
> As mentioned the patch is fairly large and may require IP review.
> Also, Samantha requested to have this bug targeted for 3.4... if
> that helps in staffing it.
Will consider for 3.4. Will likely need IP approval
due to size of fix.
>  Allow multiple debuggers to create breakpoints using the
> This is a fairly extensive feature which may require IP review. It
> would address a long standing platform debug design problem (a
> problem for Wind River at least) where multiple debuggers cannot use
> different breakpoints with the same editor. But beyond that,
> would also create a convenient and a standard mechanism to allow
> users to create breakpoints with different options enabled. For
> example, the patch includes a feature for JDT, where the user can
> switch back and forth to toggle breakpoints which are filtered to
> the currently selected thread.
> It should only take a couple of hours to try out the patches and see
> the workflow. While the patch itself is large, it is closely
> on the extension mechanism of the detail panes so I hope it'll be
> easy to digest.
Will need IP approval, but still needs more evaluation
before we consider for 3.4.
>  "Run to line" action cannot be used with non-standard
> Run to line adapters have the same problem as toggle breakpoint
> adapters, in that only one can be registered per editor. They
> have a larger problem in that they are synchronous interfaces. I
> realized the second problem only after I started working on the
> first one. I think overall this bug should be deferred till
> 3.4, but I made one small request in the bug: to made the run-to-
> line retargetable action check the debug element for the adapter.
> This way there could be multiple adapters used with the same editor,
> but the asynchronous issue would remain to be looked at later.
Deferred, but we might consider asking the target
for the adapter in 3.4, before checking the editor.
>  TreeModelLabelProvider does not cancel stale updates.
> This is mainly a performance improvment in the flexible hierarchy
> viewer. It would also make it easier to implement view data
> in DSF, but DSF can also work around this problem.
Needs more evaluation before considering.
>  Need a clarification on usage of IElement*Provider
> interfaces with update arrays.
> Comment changes, no code.
>  Flexible hierarchy provider interfaces should specify that
> they will be invoked on the UI thread.
> Past 3.4
>  NPE when closing the Variables view.
> NPE bug with a simple fix.
>  Add a modules view to the set of standard debugger views.
>  Make the detail pane UI support classes a public API.
> Both these bugs are mainly to clean up CDT code a bit, and avoid
> constantly breaking the CDT build when certain platform debug
> internal APIs change.