Breakpoints

[Vladimir Prus]

On Wednesday 15 April 2009 00:44:45 Andreas Pakulat wrote:
> On 10.04.09 13:33:20, Vladimir Prus wrote:
> > On Friday 10 April 2009 13:19:58 Andreas Pakulat wrote:
> > > I'll put my thoughts about the rest into another mail later, but wanted
> > > to say something about this paragraph:
> > > 
> > > On 10.04.09 12:43:27, Vladimir Prus wrote:
> > > > Still -- what should breakpoint widget display? We need a notion
> > > > of selected project and/or selected config so that breakpoint
> > > > widget can display breakpoints from it.
> > > 
> > > Why can it not show all breakpoints from all projects? In particular
> > > when I have two projects that work together I want to easily change
> > > breakpoints for either of them.
> > 
> > We technically can have a single list (as soon as we know
> > breakpoint->config association internally for the benefit of 'sync' state
> > display).
> 
> Why is there a breakpoint->config association?

Because config is the entity that sets breakpoints, and it should be
able to distinguish between:

  - Breakpoints that must be inserted, and are inserted
  - Breakpoints that must be inserted and are not, for any reason
  - Breakpoints that are irrelevant

In particular, display of  breakpoint in the breakpoint widget will
be decorated with different icons depending on which of the above
states is true.
 
> > > That also means that maybe breakpoints don't need to be stored on a
> > > per-project or per-launch-config basis, but could be stored globally.
> > > As a breakpoint really only needs to have a reference to a particular
> > > file, unless I'm mistaken.
> > 
> > It will also need information about what config it belongs to, and maybe
> > some other information specific to breakpoint type.
> 
> How can a breakpoint belong to a config? What if I have two configs that
> launch the same app? Or two different apps using the same shared lib and
> the breakpoint is inside a file for the shared lib?

Then, *this specific breakpoint* has to be shared between to debug configs.
Primarily, I don't want:

1. Breakpoint table showing 100 breakpoints, only 5 of them are relevant
to the current lunch config
2. Launcher having to decide, using flaky heuristics, if a breakpoint
"belongs" to it and should be inserted, or, alternatively, trying
to insert all breakpoints.

> > > > I actually think that having one selected project is generally good
> > > > from usability perspective -- maybe we should do that?
> > > 
> > > We already have that, see ISelectionController::currentSelection(). 
> > > It
> > > might need a bit of extension to be able to ask for the selection of a
> > > particular toolview or the editor area (similar to eclipse way of
> > > handling selection). And its also used already, for enabling the various
> > > project-related actions.
> > 
> > Ok, good. I am not 100% I like eclipse way of having something selected
> > or not selected in the project navigator to affect things, as opposed to
> > having a single 'project' combobox in an obvious place, but that's
> > another matter.
> 
> Quite a long time ago we decided _against_ having an "active" or
> "current" project.

Yes, I know. I'm saying that it complicates some UI tasks quite considerably.

- Volodya