Difference between revisions of "Talk:PinAndClone"

Revision as of 18:59, 8 October 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.
    
• John: I, too, think this is a valid use case. It represents an exteme approach to side-by-side multi-context debugging, and for users debugging 2-4 cores with multiple monitors, this may be the preferred workflow. We should open bugs for any of the observed problems and try to address them. Off the top of my head, I don't know what enhancements we would need to round out this use case. If you guys think of any, we should document them here or open a bugzilla to track them.

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.
      
  • John: I wouldn't say use of color is a bad solution. It just can't be the only solution. I think in some cases, for some users, colors will work well, and I would like to see that be an option. Numbering would be a second option.
    
• 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.
        • Pawel
          
  • John: Pawel, what do you mean by "paint stuff in the background"?
    

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.
          • Patrick: The global actions is valid point. I can't figure out how to be able to perform run control without stackframe, thread, process, etc... in the view. Are you suggesting putting breadcrumb in the view? I was always worry about having such a heavy UI embedded in every single view that is pinnable. Using the breadcrumb view, it is not possible to pin (scope) multi-contexts.
            • Pawel: When a view is pinned it has to know which context its pinned to. Moreover as I discovered during development of the patch in bug 145635, it would be best if the view could actually track the changing debug data model in the same way that the debug view does. This is because in some debug models stack frames are deleted and re-created on every step. So if you have a view pinnned to a stack frame, that pinned context becomes obsolete on every step. With the development of bread crumb I also created a virtual tree viewer, I planned to use this virtual tree viewer exactly for this purpose.
            • Pawel: Whether you have a visible breadcrumb embedded in the view is more questionable. It would add a lot of visual clutter, OTOH it would show information which is rather essential to understanding what's being shown in the view.
            • Pawel: Now back to the problem of tracking model changes. Debug view is the default and for the most part the only representation of the debug model which drives other debugger views. However, the debug context API allows any view to drive the active debug context in a given window. This means that an embedded breadcrumb (or a virtual viewer) which is tracking an active context in a pinned view should be capable of imitating any other view provided by some third party. I've experimented with extending the debug context API to support this using the flexible hierarchy presentation context, but it was very messy. Also, there's an API conflict due to the fact that flexible hierarchy interfaces are still provisional API. BTW, I'm sorry to unload all of this on you, but this is why this seemingly simple feature has not been implemented yet.

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.
  • John: I agree. For the common use case of comparing two variables/expressions/registers in two contexts, I think having them in a single view makes a lot more sense than having two views. I would think it would be easy to add an additional column that gives the name of the context when the view has things from more than one context.

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.

John Cortell's Comments

• John: With regards to a view's pinned context going away and coming back, and the view coming back to life for that context...how would that work? What non-transient handle do we use for a context?
  
• John: In general, I think there are far too few use cases on the wiki to shape this feature. I'm going to add additional ones. Without spelling out all the ways in which we envision developers working in a multi-context debug session, we're likely to miss important requirements.
  

October 7th Discussion

• Doug - Managing multiple contexts is the main challenge.
• Darin - Why not use multiple windows (and possibly detach views to compare)
• Natasha - Why not represent the context in the view.
  • Why not name a context?
    • Darin - naming and managing puts a big burden on the user.
• Patrick - Natasha's idea is very similar to the embedded breadcrumb idea.
  • Darin: the what do the actions act (like step) when you're in the pinned view.
• Pawel: the pinned context has to be as intelligent as the Debug view.
• Patrick: the model needs to control the scope of the selection.
• Pawel/Doug: the breadcrumb (or other context selector) needs to be able to adopt to different different debug context provider (not just Debug view).
• Darin: the context provider API has a lot of flexibility.
• Patrick: Could we allow somehow debugger clients to create multiple view instances without actually giving this feature in platform to users.
• Pawel: Wind river could supply such a patch.

possible use of color

UI Mockup

I agree that the use of colors in the original mock-up might make the text somewhat unreadable for some.

But i wouldn't dismiss the use of color out of hand.

The feature is called "_Pin_ and Clone". Why not use small colored pin-heads to denote association?

I've modified the original mock-up a bit to go back to black-and-white text, but small pins on the icons displayed in corners. Hopefully, putting a small icon on top of another icon won't be that much of a headache to implement.

Simple desktop multithreaded programs

It helps to have a simple, desktop C/C++ multi-context program in order to explore ideas. I wrote a simple multithreaded program that asks n threads to find as many prime numbers as they can in a second. This particular project is for Windows/MinGW. [[Media::Multithreaded program win32.zip]]