This is the mail archive of the insight@sources.redhat.com mailing list for the Insight project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

The main event(s)...


Hi,

Well, I think we're at the point where we need to really start cleaning up
Insight.

Fernando has already started a plugin class (thanks Fernando!), and it
occurred to me while looking over the code: It isn't at all obvious
what events are communicated from gdb to Insight.

In an effort to identify these events, I would like to propose the following
cleanup:

Currently, windows/widgets register for events from gdb by using "add_hook".
For example, to register with the GUI what to do when the target's state
has changed (stopped executing or a stack frame change by the user), windows
would do something like this:

     FooWindow::constructor {args} {
        # ...
        add_hook gdb_update_hook [code $this update]
        # ...
      }

     FooWindow::destructor {args} {
        # ...
        remove_hook gdb_udate_hook [code $this update]
        # ...
     }

My proposal is to whack all occurences of "add_hook" (and 
"remove_hook") and just extend GDBWin (a now empty class) to include a 
dispatch method for events. (I think that GDBWin was originally "written" 
with this idea in mind.) Every window interested in gdb events would 
inherit from GDBWin. Then, to "register" for an event, simply override the 
GDBWin method. So, assuming we use "update" as the method name for what we 
currently call gdb_update_hook, we would have:

     FooWindow::update {args} {
       # code for updating
     }

Events would come from gdb in the normal way, except instead of
doing:

     proc gdbtk_tcl_foo_event {args} {
        set err [catch {run_hooks foo_hook} txt]
        # blah blah
     }

We would simply have:

     proc gdbtk_tcl_foo_event {args} {
       GDBWin::dispatch foo $args
     }

(Yes, would could even call this directly from the hook in C-land.)

In the process, this would give all windows access to all event
notification, and give us "one" file (gdbwin.ith/b) which defined
all known events.

Comments? (Yes, I have an incomplete prototype working if you need/want
to see more details.)

Keith


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]