Re: [Cgdb-devel] cgdb and assembly

[Mike M. <mmu...@cs...>]

On Wed, 30 Jul 2003, Peter Kovacs wrote:

:I'm not sure that its all entirely necessary, although I definitely like
:the idea of the multiple source view windows.

The point is generality.  If we have the ability to set a window to 
any mode (source, asm, mixed), then the user has the most freedom.  
He could have a source window and an asm window going at the same 
time, or he could use one window with the mixed view, or do other 
combinations that we're not even considering right now.  The way 
we're looking at it is why impose limitations?

:So, first of all, I think that we should have Source and Mixed Assembly.
:I personally think that's the most useful view.  When you're in Mixed,
:next implicitly means 'nexti' (next instruction).

That's an interesting point.  Since we don't really have 'next' 
shortcuts anymore, I don't think it's applicable though.  We don't 
really want to intercept the user's typed commands to gdb, that is 
too nasty.  It does raise the issue of whether we should reintroduce 
the shortcuts, maybe through :commands.

:I'll have to think about the multiple source views problem.  I'm
:thinking some sort of event system, however I'm not sure that would be
:the best thing to bundle into libtgdb which we eventually hope to be
:used by other parties.  The idea would be that tgdb would output
:different types of events like 'view source' events or 'terminal
:output'.  cgdb would be responsible for catching these events, and
:distributing them to the right places.  Seems a tad overly complicated,
:but it might be a step in the right direction.
:
:Another idea would be to register a series of callback functions.  So
:when you create a source view, you register with tgdb and get called
:whenever there is a source view update.  The problem with this, (and
:with the event based approach) is how do you handle source file changes.
:Do you wipe out all the windows?  Do you refresh all the windows with
:the new source file?

Bob & I were thinking of using a callback system for this, I 
believe.  The event system is tough because the main loop for a UI 
is always going to be a select() loop.  To have an event-driven 
system means we'd have to somehow get the UI out of the select loop 
so that we can call event-handling functions.  It seems simpler to 
just use callbacks.

:
:- Peter

Mike