Talk:PinAndClone

Pawel's Points to consider

Thank you Patrick for pulling together this page. We've had discussions about this feature numerous times over many years so I'll try to summarize the biggest questions and points that are bound to come up here. BTW, these points were raised by different people, so I'll state my opinion separately on each point. Please feel free to just edit the list below so we can keep the discussion organized.

Why not use dedicated windows per each debug context?

Using a single window per active debug context keeps the UI simple and uncluttered. Rather than having multiple instances of individual views, we could improve and enable multi-context debugging using multiple top-level windows.

• Pawel: There is a lot of validity to this POV, mainly because the Eclipse UI is already difficult to grasp (toolbars, menus, icons, etc.) and adding multiple view instances will only make it worse. The only way to deflect this criticism is to demonstrate that this feature will make the workflow simpler and more intuitive. So far I don't think that's the case.
• Patrick: I assume top-level windows means workbench windows. I think it should be user preference to choose single workbench window with multiple debug views or multiple workbench windows with single debug view. I see pros and cons in term of screen realestate and how views are docked together for comparsion purpose.
• Pawel: OTOH the multiple windows model in Eclipse has a lot of problems. As Patrick pointed out in one of the bugs, the Debug view makes it difficult to focus on onw debugging task. I've also discovered quirks in using multiple windows, e.g. only one window can have a modal dialog shown, and activated contexts in one window can disable toolbar icons in the other window.
• Patrick: Here is a bugzilla for the modal dialog that I have filed awhile ago, 107256.

How will the user know what his view is focused on?

• Pawel: Colors are not a good solution (Wind River's product uses colors). Embedding a breadcrumb in a view is another option, but this could prove to be a visual nightmare.
• Patrick: I agree that colors might not be a good solution, it can quickly turn into a rainbow. What about overlay the icon in the Debug (Launch) view with a number that matches the number for the pinned view?

When you're in a pinned view, then which context do run control actions apply to?

• Pawel: IMO, the run control actions should be moved out of the Debug view and to the top-level toolbar. Then the run control actions should logically follow the active context of the active view. If run control actions stay in the Debug view, it would be too weird to have them act on something different than the selection in that view.
• Patrick: I think having the run control actions at the top-level toolbar is something that our user would like to have as well, but I am not able to grasp the concept of controling the debug context within the pinned view. Perhaps I mis-understand your idea. My idea of pinned view should not react to context change for selection that is not pinned (scoped). i.e if the expression view is pinned to multiple contexts, thread A and thread B, than the view should indicates the active context that it used to provide the content. The user can change the expression view input by selecting between thread A and thread B, and the view will update to indicate the active context. However if there is a thread C, than selecting this thread will not cause the expression view to switch context.

Why not a multi-context expressions view?

• Pawel: A single view that allows the user to see and view variables and registers from multiple contexts could solve many of the same issues as multiple view instances... if executed well. In order to implement such a view, many of the same technical problems would need to be solved as with pinning whole views. Honestly, I can't tell which would be more useful without trying them out.
• Patrick: This works if the contexts have the same structure, I am not sure how to present this when the contexts provide different structures. i.e watching the input of Context A and compare it with the output of Context B, but the underline data structure can be completely different. Context A can be a data structure on an 32bit core, where as Context B can be a data structure on a 16bit core, or Context A has 10 fields in the data structure and Context B has 2 fields in the data structure. etc...
• Patrick: Also, we need to be consistent for pin&clone for other views as well. i.e disassembly, memory, graph, etc... If we can agree on a common behavior that is applicable for any view, than it will make the user experience much easier without knowing different ways to compare views.

Why not a compare dialog, or compare layout in a single view?

• Pawel: If your main use case is to allow user to compare variables and registers from multiple contexts, I think a dedicated layout is a much better workflow than making the user layout two views with titles + toolbars + separate tree controls. I remember that argued here that a compare mode in a single view is not the same and I agree. But if we had a such a mode would the value/cost equasion still make any sense for pin+clone?

Boris' comments

"über-debug" view

• Boris: Could the different views be combined into one? If the stack, variables, registers etc. were just different sections of a single view (as an example to follow, think of the Hierarchy view with its two sections), it would be very clear which variables section belonged to which stack, and all you would have to do is support opening more than one instance of this new "über-debug" view. You would lose some flexibility w.r.t. view arrangements, but you could offer a number of configurations for the sections that make sense. (If the views were e4 parts - i.e. without reaching out to singletons - , it would be trivial to do this. Not sure how realistic it is given the current code structure.)
• Pawel: I've played around with this idea in the past as well. The debug views we have (variables, registers, watch, etc.) are a really ancient concept, I assume we can do better :-) My concept was to create a more intelligent version of the expressions view that was capable of displaying any type of debug data (threads, breakpoints, etc.), and let user specify which data he's interested in seeing. These could be a mix of items pinned to specific contexts and ones that update with the active window context. I've never had enough time to prototype it though.