Re: Adding a gdb console to nemiver...

[Dodji Seketeli <dodji gnome org>]

Seemanta Dutta a écrit :

> I saw the TODO list the other day and thought that it would be interesting
> if I take up implementing the 'GtkTextView' based gdb console for Nemiver.
> This should work something similar to the gdb console that we get for DDD
> and the user should be able to give all valid gdb commands to it.
> 
> I had some queries regarding the same :
> 
> 1. Is someone already doing any work on this? If yes, then I can join them?
> Or else, I want to jump start this new 'feature' work.


Nope. No one is working on this one yet.

At some point, I have been thinking about adding some scripting support
to Nemiver, like being able to talk to the IDebugger interface using a
very small dynamic language like Lua. Then, on top of that, write a
gdb-like console in that dynamic language. The nice side of effect of
this would be to give people the ability to quickly write their own
scripts to do custom debugging stuff like tracking some reference
counting bugs in their target software etc.

But alas, I haven't had time to start this yet. So my ramblings
shouldn't stop your energy. If you feel like starting to work on a
console, that'd be interesting.

> 2.I guess the best place to add the console would be side-by-side the
> various consoles like terminal, call stack, memory etc that are already
> there in nemiver currently,
> visible at the bottom pane.

Yes.

> 3. I went through the code and felt a bit confused :(

Okay this is going to be long.

It all happens in nmv-dbg-perspective.cc, in the type DBGPerspective type.

The DBGPerspective type represents the Debugging Perspective. A
perspective is a set of widgets that collaborate to give the user a
certain experience. The Debugging Perspective is the set of widgets that
collaborate to provide the user with the debugging experience. One could
imagine a ValgrindPerspective that would provide some memory debugging
experience or whatnot.

The terminal output, call stack, memory etc, are called "views" in
Nemiver lingo. These views are "packed" in the "status notebook". The
status notebook is what you have called the bottom pane earlier.

In the code today, each view can be added/removed to/from the status
notebook, even if you don't see that in the current UI currently.

So if you want to create a new view that is a widget named a "foo",
which is of type Foo, you will have to add a new method to
DBGPerspective, called DBGPerspective::set_show_foo_view(bool);.

When DBGPerspective::set_show_foo_view(bool) is called with a boolean
argument set to 'true', that means the system is asking the debugging
perspective to show the foo view. On the contrary when
DBGPerspective::set_show_foo_view(bool) is called with a boolean
argument set to 'false' it means the system is asking the debugging
perspective to hidde the foo view. So the code of
DBGPerspective::set_show_foo_view(bool) must act accordingly.

As an example, you can look at
DBGPerspective::set_show_target_output_view or
DBGPerspective::set_show_call_stack_view to see what they do and mimic
their behaviour.

For now, the different views are shown/hidden in the function
DBGPerspective::init_perspective_menu_entries[1]. So make sure you add a
call to DBGPerspective::set_show_foo_view(true) in there once you've
coded it.

That should I hope get you started.


> Also, can you please tell me what would be the flow?
> Like, first create the widget using glade, and then generate the xml file
> and then use libglade somewhere within the code etc. etc.

I think first, I wouldn't bother too much with UI related stuff. I'd try
to create a console in text mode, outside of the UI, using the IDebugger
interface. Yes, that's like writing a gdb-like text console. The main
goal here is to come up with a reusable type (read class) that'd be used
in the UI later. For instance a DBGCommandInterpreter[2] which one could
feed with some commands, and that would be expected to execute them,
prompt for errors in the commands etc, execute them and hand out some
output. That interpreter could then be usable either in a text console
or in a minimal graphical console.

But again if you feel like hacking the UI first, no problem :) It's your
time.

[1] Which makes me think that function name is dumb. It's the relique of
some ancient cruft. I must change that.

[2] That name is too long :) A better name would be nicer ;)

Cheers,

Dodji.