Breakpoints

[Vladimir Prus]

On Friday 10 April 2009 00:10:32 Niko Sams wrote:
> On Mon, Apr 6, 2009 at 11:05 AM, Vladimir Prus <ghost at cs.msu.su> wrote:
> > I think the big question is not whether the C++ class implementing the breakpoint
> > model is the same for all debuggers, or not. The question is whether there's a single
> > breakpoint model instance in KDevelop session. Because it a breakpoint is given
> > a pile of breakpoints, some of which are for different projects, or different
> > launchers, it might very well be confused. In particular, current breakpoint
> > widget has a 'state' column, that can be either 'dirty' or 'synchronized'. This
> > is somewhat important for C++, since breakpoints in shared libraries are not resolved
> > until shared libraries are loaded, and it would be nice to see if that worked out.

> Why can't the BreakpointWidget ask the current DebugSession about this state?

Well, this state is displayed now :-)

> > If breakpoint model includes breakpoints from all project, breakpoint widget cannot
> > figure which breakpoints *should* be inserted, and cannot meaningfully show state.

> But on the other hand it might be useful to set a breakpoint in a
> library and start the
> application (differnt project).

It might be, but it's not unreasonable to ask that you express your intention
explicitly -- like setting the breakpoint in library in the debug config associated
with the project.

> > Maybe, the right solution would be to explicitly introduce 'current launch config',
> > make breakpoints be associated with a config by default, and show only breakpoints
> > in the current config. We might need 'global' breakpoints -- but I'd suggest not
> > doing this until we see obvious need.

> Do we have always a launch config? What I'm thinking of - a xdebug
> session that is started
> by navigating around in an external browser - we don't neccesarily
> have a launch config for that (?)

Well, we can have one created implicitly.

> So the question is, where should breakpoints get stored:
> - per launch config (if you switch launch config breakpoints are
> removed/restored)
> - per project (there is just one set of breakpoints per project)

That's a valid question. Per-project might be a better default, but
not that a launch configuration is not necessary associated with
a project. So, maybe, store in project if there's project, and in
launch config otherwise? Of course, I'd imagine the code will be
structured the way that make it possible to easily change this
decision at a later time, should we need so.

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. I actually think that
having one selected project is generally good from usability
perspective -- maybe we should do that?

- Volodya