| Re: [platform-debug-dev] Re: [dsdp-dd-dev] Multicontext debugging proposal |
Samantha Chan wrote:
A pluggable UI in the selection dialog seems like an excellent idea. I was planning to simply use a TreeModelViewer which would make the dialog as scalable as the Launch view, but I imagine that for parallel computing the Launch view itself is probably not all that useful.Hi, I have also reviewed the proposal again and have consulted my team on some of the issues. I have added more comments in the proposal as well. Re: Select Debug Context Dialog from View or Editor The dialog is to show different available context that is available for the user to switch between. The dialog will have a drop down to show available context root. A context root contains available context. (e.g I assume the context root is the root in the Debug View where it is the Launch Manager.) Having a dialog to display available context is not scalable, especially in parallel computing environment where we can have thousands of processes and threads. We need a way disable this feature all together to avoid the scalability problems. Or, we need a way to override the control used to displayed the context to allow us to plug in fancier UIs to show context in a scalable manner. The launch view takes up a lot of screen real estate: it needs to be wide enough to fit the long labels of stack frames, and it needs to be at least high enough to show all the levels in the tree (since a stack frame is 4 levels deep). As a user I try to configure my view layout to have as much screen dedicated for the editor as I can, even on a 1900x1200 screen... maybe it's a bit of an obsession but I'm probably not alone :-) What's frustrating to me about the Launch view is that most of the time I actually don't care about the data that's in it, because as a plugin developer I usually run one program at a time, I can figure out what thread I'm in based on the code that is executing and I mostly look at the top stack frame.Re: De-centralization of the Launch View The proposal suggested that a default context provider is created for a window. The default context provider is not tied to any view. The Launch View is simply a listener to the default context provider. This allows the Debug Perspective to operate without the presence of the Launch View. The concern here is that without having a view tied to the default context provider, it is extremely confusing to figure out what the current debug context is. I agree that having another "kind" of view to drive the active debug context is a good idea, but not having a view at all can cause usability problems. For example, if the user is debugging a multi-threaded application, and the user is suspended at Thread A, and debugging. Meanwhile, another thread, Thread B, is suspended. Without a view to indicate that something else is suspended, how does the user know that another context has become available? What are some of the reasons why we do not want a view to drive the active debug context? Why is having a view opened to drive the current context problematic? I completely agree with you that without the Launch view present there needs to be an obvious indicator of the current debug context. I was planning to try to use the status bar for this purpose, but I really don't know how well that's going to work out. True, having a global toolbar is primarily intended to allow Launch view-less debugging. Ironically enough though, in our product we have the opposite toolbar real-estate problem. We have too many buttons in the Launch view itself.Re: Global Debug Actions Toolbar Since the Launch View does not need to be present all the time, actions from the Launch View's toolbar need to become global. This causes a couple problems for us: - Real-estate on the global toolbar - this makes the global toolbar more cluttered. - When invoking action on the toolbar, how does the user know what context the action is invoked on. e.g. if I press resume, which thread am I resuming, without having the Launch View tells me which thread is in focus? We also believe that this is a side effect to not having a view to drive debug context. If a view is always present, then there will be no need for global debug actions toolbar. I absolutely agree, these are major changes in the UI and I think there is a lot of risk in getting it "right". If I had the opportunity I would have prototyped this back in July, but I know that at this point already it's getting late for these kinds of changes. In any case, my intention is not to change the exiting default workflow for users, I only want to give the opportunity for advanced users to optimize their workflow.Re: Changes in the workflow As indicated in the proposal, this means that debugging workflow can be changed significantly. Do we have enough time to get this right in the 3.4 timeframe since the changes are so drastic. We have many debuggers built on top of the platform. We are concerned that the changes in workflow can cause a lot of confusion with our existing users. One of our requirements is that this work item should not break existing debug adapters. Existing debug adapters should just work without much migration work involved. This could be an ugly problem for implementing these changes.. the alternative would be to add a whole bunch of duplicate methods to IDebugContextService.Re: Changes in behavior with addDebugContextListener(IDebugContextListener listener, String partId) If the client has registered with a partID that does not exist, the proposal is to change the behavior to have the listener get a context events from the default context provider. In my opinion, when the client has specified a part id with the listener registration, the client intends to filter out events from views that it does not care about. Otherwise, the client could have registered without the part id. Changing this behavior could break existing clients and introduce compatibility issues. Thank you for all the feedback. Cheers Pawel
|