Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:PinAndClone"
m (New page: === 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 b...) |
m (→Pawel's Points to consider) |
||
| Line 1: | Line 1: | ||
| − | + | == 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. | 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? | ||
Revision as of 00:39, 28 September 2010
Contents
- 1 Pawel's Points to consider
- 1.1 Why not use dedicated windows per each debug context?
- 1.2 How will the user know what his view is focused on?
- 1.3 When you're in a pinned view, then which context do run control actions apply to?
- 1.4 Why not a multi-context expressions view?
- 1.5 Why not a compare dialog, or compare layout in a single view?
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?