Breakpoints

Andreas Pakulat apaku at gmx.de
Wed Apr 15 18:37:08 UTC 2009


On 15.04.09 20:41:32, Vladimir Prus wrote:
> On Wednesday 15 April 2009 14:25:13 Andreas Pakulat wrote:
> > On 15.04.09 13:06:38, Vladimir Prus wrote:
> > > We'll have current launch config -- we already have it, and other IDEs have
> > > it too. Newly added breakpoints are associated with the current launch config.
> > 
> > No, we have a "default run", which is executed if you don't choose a
> > different one. But if I debug two applications at the same time, I don't
> > want to have to switch the "current launch config" each time something
> > happens in the other app. 
> 
> How often do you debug two applications at the same time?

About once a week currently. In fact I might be doing this even more often
once KDevelop support java+debugging java apps.
 
> > Also I don't see this being needed at all, a debug plugin, when starting an
> > app, can see _all_ breakpoints that have ever been set by the user. It can
> > then try to set all of them,
> 
> And then will get errors setting half of them, and will display breakpoints
> as problematic in breakpoint widget, and users will wonder what broke.

Or they might realize that the breakpoints that are not "active" simply
don't belong to the application(s) that have been launched. As I said
before, popping up message boxes when a breakpoint cannot be set is not a
good way to inform the user of that. The breakpoints already have a "set
but not yet active" visual state, so we should make use of that.

> Anyway, it seems like we're not getting closure via email -- can we schedule
> a real time chat -- say IRC or Skype?

You mean regarding a "Current launch config"? We won't reach a conclusion
on IRC over that anyway. IMHO its wrong and I won't change my mind and
there's at least one other IDE out there that doesn't have a "current
launch config" or "current debug session". And debugging in that IDE works
quite well, even if its not java.

Andreas

-- 
It's all in the mind, ya know.




More information about the KDevelop-devel mailing list