kdevelop drkonqi integration

[Andreas Pakulat]

On 23.04.09 12:27:06, George Kiagiadakis wrote:
> On Thursday 23 April 2009 09:39:48 Andreas Pakulat wrote:
> > On 21.04.09 17:06:48, George Kiagiadakis wrote:
> > > and disallows fetching a backtrace or starting debugging with
> > > gdb. So, after starting debugging with kdevelop, drkonqi is completely
> > > useless as it can't generate a backtrace and thus it is unable to report
> > > a bug.
> >
> > IMHO if someone wants to debug the application that crashes with either
> > plain gdb or KDevelop we can assume that this person at least remotely
> > knows what he does and doesn't need the crash handler anymore after
> > finishing debugging the app. So I think your solution 2) of shutting
> > down drkonqi2 when kdevelop has attached to the process is the right
> > one.
> 
> Ok, so I think the plan should be this:
> When the user clicks the "Debug in kdevelop" button, drkonqi sends a SIGCONT 
> to the process and a signal to kdevelop that debugging should start. Then, 
> Kdevelop attaches to the process first and then it calls 
> org.kde.KApplication.quit() on drkonqi.

Can we do that the other way around? Let KDevelop start its attaching
first and then send the SIGCONT? Else the app will probably be away as
soon as KDevelop tries to attach, because after the crash it'll just be
removed from the process list. So the order would be:

- send a signal to kdevelop to attach to the process (kdevelop's gdb
  will start and try to attach, but this is suspended atm)
- send a SIGCONT to the process (kdevelop's gdb resumes, loads all the
  libs and then is attached)
- kdevelop quits dr. konqi via dbus

Andreas

-- 
You work very hard.  Don't try to think as well.