Breakpoints

[Andreas Pakulat]

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?

> > 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?

> > > 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.

Andreas

-- 
Advancement in position.