Breakpoints

Niko Sams niko.sams at gmail.com
Wed Apr 15 18:57:09 UTC 2009


On Wed, Apr 15, 2009 at 8:37 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> 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.
A very common use case would be Ajax applications where you develop
Client-Side (JavaScript) and Server-Side (eg. Php) at the same time.
If I had an IDE that supports this, I would use it :D

>> > 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.
I think this would be a good solution.


I have another use-case:
a project with 2 unit-tests (2 targets). If I switch the target I don't want to
loose all breakpoints


Niko




More information about the KDevelop-devel mailing list