Bug 260075

Comment 1 Darin Wright 2009-01-08 12:49:27 EST

Generally, I like the approach of a bread crumb to minimize the screen realestate that the debug view consumes. This makes the debugging experience less intrusive. However, I think there are issues around using the status bar to acheive this (wrt to action enablement and contributions like "Copy Stack Trace", etc), and the introduction of another set of actions to the top level toolbar.

Advice/guidance from the workbench team/bread Java crumb implementors would be helpful.

Comment 2 Dani Megert 2009-01-09 09:48:55 EST

When we did the Java breadcrumb, we also prototyped and rejected a toolbar based solution for various reasons - most of which now surface as problems in this Debug breadcrumb:
- action handling: all actions of the active part are still active when 
  clicking on an item (not the arrow) - this is a no-go
- the concept of selection and/or site doesn't exist for toolbar items which 
  makes it hard to (re-) use existing actions
- being a toolbar causes problems as there is only one per top, bottom, left 
  and right ==> other toolbars at same position get squeezed/wrapped
- it offers too much functionality/interaction for a toolbar - this is an 
  uncommon UI concept and would have to be blessed by UI lead first
- docking the toolbar left or right makes it unusable - if the current approach 
  is pursued then this must also be supported

Other things I noticed:
- activation issues:
  - when it got activated I was surprised that it is at the bottom: I would 
    expect it to appear on top - for me it is unusable if at the bottom, 
    however placing at the top causes problems with other tool bars (see above)
  - strange that I get both: Debug views plus breadcrumb
  - appears in all windows
  - can no longer be removed
  - activates action sets that don't go away after debugging and then use up 
    space in my main tool bar

- many non-object contribution actions are a must and a no-go if they aren't 
  there, e.g. 'Copy Stack'

- usability
  - selecting an element should automatically expand as far as possible
  - clicking on tool bar item while drop down is open should not only close it 
    but open the newly clicked
  - should have (or use) same filtering/grouping as in Debug view

I strongly recommend to add this new feature as new "mini" or "breadcrumb" layout mode to the Debug view. Given that the current Debug breadcrumb also needs to add more debug actions to the toolbar in order to be usable at all, it wouldn't use up much more space with the view approach. Like, e.g. the JUnit view, the Debug view could also automatically select the right layout when it gets resized. In addition, there's more freedom in placing it inside the workbench window and it can have different layouts in different workbench windows.

Comment 3 Pawel Piech 2009-01-13 19:41:09 EST

(In reply to comment #2)
> When we did the Java breadcrumb, we also prototyped and rejected a toolbar
> based solution for various reasons - most of which now surface as problems in
> this Debug breadcrumb:
> - action handling: all actions of the active part are still active when 
>   clicking on an item (not the arrow) - this is a no-go
> - the concept of selection and/or site doesn't exist for toolbar items which 
>   makes it hard to (re-) use existing actions
> - being a toolbar causes problems as there is only one per top, bottom, left 
>   and right ==> other toolbars at same position get squeezed/wrapped
> - it offers too much functionality/interaction for a toolbar - this is an 
>   uncommon UI concept and would have to be blessed by UI lead first
> - docking the toolbar left or right makes it unusable - if the current approach 
>   is pursued then this must also be supported

Thank you Dani for this feedback.  I personally still really like the concept of using the status bar for selecting/tracking debug context, and having used it for a few weeks I also think it's quite productive.  But I also, agree with all the points you raised.  For me, especially the first two bullets above are the most difficult to overcome. 

> 
> Other things I noticed:
> - activation issues:
>   - when it got activated I was surprised that it is at the bottom: I would 
>     expect it to appear on top - for me it is unusable if at the bottom, 
>     however placing at the top causes problems with other tool bars (see above)
>   - strange that I get both: Debug views plus breadcrumb
>   - appears in all windows
>   - can no longer be removed
>   - activates action sets that don't go away after debugging and then use up 
>     space in my main tool bar
> 
> - many non-object contribution actions are a must and a no-go if they aren't 
>   there, e.g. 'Copy Stack'
Once again, I agree here as well, although I've been able to address some of these since I posted the feature that you tested.

> 
> - usability
>   - selecting an element should automatically expand as far as possible
I don't understand why this would be desirable and I don't see the JDT breadcrumb working this way all the time.  If I select a package it does expand, but if I select a class, the breadcrumb opens it... instead of expanding.  For the debugger any context that's visible can be activated, so I'm not sure how I would draw the distinction. 

>   - clicking on tool bar item while drop down is open should not only close it 
>     but open the newly clicked
>   - should have (or use) same filtering/grouping as in Debug view
Agreed.

> I strongly recommend to add this new feature as new "mini" or "breadcrumb"
> layout mode to the Debug view. Given that the current Debug breadcrumb also
> needs to add more debug actions to the toolbar in order to be usable at all, it
> wouldn't use up much more space with the view approach. Like, e.g. the JUnit
> view, the Debug view could also automatically select the right layout when it
> gets resized. In addition, there's more freedom in placing it inside the
> workbench window and it can have different layouts in different workbench
> windows.

In talking with Darin and from your earlier emails, we also came to this conclusion.  I implemented the Debug view "compact mode" solution and posted the patch for it in bug 252677.  I think it addresses all the issues you raised here, and though I haven't used it myself yet, I think it has some other advantages too: e.g. being able to very quickly go between the full view and the breadcrumb.  If you'd be interested in trying out this updated feature, I could try to post it to the Debug update site again.

Comment 4 Dani Megert 2009-01-14 03:10:27 EST

Regarding the auto-expand: when I was testing I had two launches each with one thread that was stopped. When I switched e.g. between them I was expecting that it directly goes to the position where it stopped. Of course if all threads are stopped then this does not work. In that case I probably would expect to remember the last expansion state per launch, so that I don't have to expand all the time manually.


>If you'd be interested in trying out this updated feature, I could try to post 
>it to the Debug update site again.
Might be useful for others. I prefer to use the patch.

Comment 5 Pawel Piech 2009-01-14 14:18:21 EST

(In reply to comment #4)
> Regarding the auto-expand: when I was testing I had two launches each with one
> thread that was stopped. When I switched e.g. between them I was expecting that
> it directly goes to the position where it stopped. Of course if all threads are
> stopped then this does not work. In that case I probably would expect to
> remember the last expansion state per launch, so that I don't have to expand
> all the time manually.
Ah I see.  I agree that the expansion state should be saved and I though that this was actually working, but maybe I haven't tested it well enough.  Thanks for the clarification.

> >If you'd be interested in trying out this updated feature, I could try to post 
> >it to the Debug update site again.
> Might be useful for others. I prefer to use the patch.
Glad to hear it.  If someone else requests it, I'll do the update then :-)

Comment 6 Pawel Piech 2009-01-14 16:05:24 EST

(In reply to comment #5)
> Ah I see.  I agree that the expansion state should be saved and I though that
> this was actually working, but maybe I haven't tested it well enough.  Thanks
> for the clarification.
The expansion state is preserved, but only if a selection is made.  If the drop-down is closed because the focus was lost, the expansion state is not preserved.  IMO this behavior is OK, though it is possible to change it.  Also, I noticed that collapsing of nodes is not preserved, which I'll definitely fix.

Comment 7 Darin Wright 2009-06-17 12:26:44 EDT

Marking as works for me. Users should open new bugs as required.