Difference between revisions of "Talk:PinAndClone"

Revision as of 13:55, 29 September 2010

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?
    • Pawel: We have that too, though our version is so small that it may as well not be there. Also we get constant feedback from users that icons should not be used to convey vital information, only visual hints.
• Pawel: If all possibilities were on the table, we could hi-jack drawing of the tree control of the Debug view and paint stuff in the background. But I doubt this would solve the problem also. Users have a well ingrained concept of the active context, breaking through that conception is difficult.
  • Patrick: Could this be done as a vendor specific, have a way to allow vendor to customize the Debug view (label, icon, etc...). The SWT/JFace tree allows decoration extension and can be use to extend the label. However, I am not able to do this for the Debug view, I believe it overrided the standard behavior of SWT/JFace.
    • Pawel: Unfortunately no, I don't think it would be possible to allow individual debuggers customize the SWT control without exposing too much of an API. Currently none of the Debug view implementation details beside the view ID are in the API.
      • Patrick: Without touch the SWT, the debugger can provide color and icon using the flexible viewer. Is this mean debugger can customize the Debug view on their own? So as long as Platform opens up multiple instances of views and be able to switch debug context provider, than individual vender should be possible to customize how Pin & Clone works. It would be nice to come to an agreement as an community and have a common solution. I am hoping this will happen, such that the standard debugger (DSF/CDI/etc...) will behave the same as any vendor specific debugger.

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.
    • Pawel: If you're in a view that is pinned to some thread and you say "step". Should you step the thread that the view is pinned to (so that your pinned view's values update?) Or should the thread that is active in Debug view step?
      • Patrick: I think the run control should follows the Debug view selection. If the run control uses the active view's pinned context, than you need to know which context is pinned (can be multiple - if pinned support multiple contexts) and which view is active (you might have switched the view focus around by clicking other views). IMO, having one single view to figure out the active debug context is much simpler than multiple views that provides debug context under different condition (in this case, pinned).
        • Pawel: The counter point is that there some global actions for which you do want to have the active debug context derived from the current view: E.g. toggle watch point. Making exceptions on case-by-case basis could force us to create an ugly API and potentially a confusing workflow. I'm not saying it can't be done, but it is a problematic area for this feature.

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...
    • Pawel: I think this comment was meant for the compare view. If so, then I agree that it's not a simple problem to solve and the tool would sometimes get things wrong. But this is true for the source compare tool also, yet it's limitations doen't make it useless.
  • 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.