[platform-ui-dev] Debug contexts

[Jared Burns <jaredburns@xxxxxxx>]

We've poked around at the context support some more and we've got something 
that's able to open/close/promote views as the user changes between debug 
models. However, there are some outstanding issues that make the current 
support hacked together and ugly. :-)

Bug 50033 - [Contributions] Context change notifications not sent
 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=50033>

Bug 50094 - [ViewMgmt] API to close a view without instantiating it
  <https://bugs.eclipse.org/bugs/show_bug.cgi?id=50094>

Bug 50171 - [EditorMgmt] No part listener notifications sent?
  <https://bugs.eclipse.org/bugs/show_bug.cgi?id=50171>

I've also hit two snags that I haven't filed bug reports for. I tried asking 
about these on the newsgroup first, but didn't get any replies.

1. Access to view stacking information in the workbench?
In our current implementation, I end up with a handful of view IDs that are
considered applicable for the currently selected stack frame in the Debug
view. The goal is to make as many of the views in this collection visible
as possible.

The problem I'm having is that I haven't found any API related to how views
are currently stacked (tabbed). For example, say I have views A, B, and C
stacked on top of each other. Views A and B are both be in the collection
of "applicable views," so we'd like to make sure one of them is visible.
Also, we want to make sure that if either of these views is currently
visible, that view will be the one that's chosen so it will stay on top.

Is there any way for us to programatically determine that views A and B are
stacked? If so, our job is easy. If not, could this API be provided? If
such an API is not possible, then there's a follow-up question.

If we can't tell which views are stacked on top of each other, we can
achieve the results we want the hard way by activating all of the
applicable views, making sure we activate the currently visible ones last.
In the end, this has the correct result, but it creates a ton of angry
flickering in the UI. Is there any way we can stop the flickering? I tried
accessing turning redraw on and off for the workbench's shell, but that had
no effect.

2. Start listening to part activation after perspective initialization?
(This was before I stopped getting any part open/close notifications as per 
the bug report above)
I want to listen to part open/close notifications that originate from the
user. The problem I have is that I can't tell the difference between an
IPartListener#partOpened(...) notification that happens when the user opens
a view and one that happens when a perspective is first created.

I'd like to delay the registration of my part listener until after the
perspective is finished opening its views, but I haven't found an API that
lets me know when this occurs. Does such an API exist? Is there any other
way to tell between the user opening views and the workbench doing it at
startup?

Any help you can offer so we can keep moving forward would be appreciated.

Thanks,
- Jared