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]

Re: The main event(s)...


I think this is something we should have done long ago.

Maritn


On Thu, 22 Feb 2001, Keith Seitz wrote:

> 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]