[Qt-creator] Plugin questions (internals)

[Enrico Ros]

Thanks Andre',

On Monday 13 July 2009 21:06:32 Andre Poenitz wrote:
> On Mon, Jul 13, 2009 at 05:40:15PM +0200, Enrico Ros wrote:
> > Hello, I'm having real fun developing a plugin for Qt Creator (no, I'm
> > not integrating plasmoids ;-)). Now I'm facing some challenges and I'd
> > like to know the best way to proceed:
> >
> >  1. [the trickiest] My Plugin has to use the Debugger plugin (for example
> > to execute gdb commands) and the Debugger plugin has to use My Plugin
> > (for example to execute some more gdb commands on debugging startup). How
> > can I untangle this?  a. Should MyPlugin be used by Debugger?  b. Should
> > Debugger expose its internal classes or interfaces (to allow the usage by
> > other plugins)? c. Any other suggestion is welcome.
>
> Is this gdb specific? Or does it work with any debugger?

Current implementation is for GDB, but I have to make backends for the other 
debuggers too.

> >  2. I may have the need to control the (debugging) execution, for example
> > to stop the program, execute a couple of debugger commands and start it
> > back. Is this available via the Debugger plugin internals or is it
> > exposed in some session/application wide way? Are there any callbacks to
> > update My Plugin's actions when the execution state changes?
>
> There's  DebuggerManager::startChanged(int newstatus), but that's meant
> only for purely informational purposes, not to drive higher level
> application logic.

If I understand correctly, I can't use DebuggerManager from outside the 
Debugger plugin (or I have to make Debugger linkable by other plugins, link 
it, export the symbol, and call addObject to the plugin manager to register 
DebuggerManager), am I right?

What I'm trying to do is to interact with the debugger plugin to extract other 
kind of information from the running application, like stack traces at certain 
point in time, etc. I already have too many classes (including all the cool 
visualization stuff) that can't be merged within the Debugger plugin, it has 
to live as a plugin of its own, I think.

This is why I'm trying to acheive the best separation even if sometimes the 
Debugger has to query My Plugin (for some values) and My Plugin has to listen 
to debugger status changes (for inferring when it can act) and issue some 
debugger calls (stop, query Debugger values, continue execution).

Have you got any ideas about that?

> >  3. I see that I can have many running executables for the code I'm
> > editing but up to 1 (i think) debugging session. Is the 'single debugger
> > per qt- creator' enforced? Where can I look for this 'debugging session'
> > properties? And for the 'running sessions' ?
>
> It currently is basically 'one instance per Creator', but it's not
> formally enforced.  There might be some refactoring needed to have more
> than one active debugging session, but it should be feasible.

Do you plan to do such refactoring? If you do, can you expose the concept of 
"running sessions" and "debugging sessions" to the outside? The current 
behavior is good for me, I'm asking just to know how to adapt to future 
changes.

Enrico

--
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Se ci racconti i tuoi gesti d'amore per il tuo cane, Cesar ti premia. Partecipa anche tu!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=9204&d=14-7