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.
• 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.

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.

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.

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.

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.