GDB/MI (Was: Embedded development)

[Vladimir Prus]

On Wednesday 14 September 2005 11:57, Richard Dale wrote:

> > Where there will be some possible debugger interfaces (ValueAccess,
> > Breakpoints, MemoryReading) and specific backends will implement whatever
> > interfaces they can. The debugger UI will then query supported interfaces
> > and enable/disable the specific windows. Say, python debugger backend
> > will report that it can't display raw memory, and the memory viewer will
> > disappear.
> >
> > How does that sound?
>
> Yes, that sounds good to me. If we use Qt4 custom models for the variable
> viewer QTreeView, and frame stack widget that should make it easier to
> seperate the UI from the debugger code for a specific language.

As a side question: say I want to completely change visualization of a certain 
item in frame view. Instead of text, I want a combobox saying "More frames 
follows" and allowing to select a number of additional frames to show.

How do I do that with Qt4 views architecture? It looks like I'd need 
QListView::setItemDelegate and that "special" item, which somewhat breaks 
separation. I would prefer it if QAbstractItemModel could specify specifing
rendering code. 

> On the other hand, I think it would be a good idea to get the current gdb
> debugger working with MI first, and the code as clean as possible before
> trying to re-architect it. I would rather merge a working ruby debugger
> with a working gdb debugger, and work out the common architecture for
> KDevelop4 as we do that.

Let's see. First of all, I need to finish some work on current debugger 
(memory and register views). That goes to KDevelop 3.4 branch.
Then I'd look at bugs -- some really better fixed. And then, I'll start 
playing with MI. That all is going to happen on KDevelop 3.4 branch,
I don't know yet when I'll port this to Qt4.

- Volodya