[Goe-dev] Browser2 and events

[<rb...@ce...>]

I couldn't find a floppy disk this morning, so my update won't come till
tomorrow. The new browser is almost complete, and I might even have it
done by tomorrow. The framework I've set up is allready being effective,
each piece I add is working right away and is easier to code.

I made a comment in the souce code, but thought I could ask you about
something too. I am trying out an event handler scheme. Assuming you have
a fixed point font, lets demonstrate.

+--Browser
  |
  +--Panes
  | |
  | +--PackageTree
  | |
  | +--MethodList
  |
  +--Editor
    |
    +--Code


So when instantiated, MethodList runs

$self->{owner}->add_event(
  'curPkg changed' => sub{$self->refresh} );

So that its owner (Panes) will be sure to tell it if curPkg (the package
currently being viewed) changes. When someone clicks on a new package in
the PackageTree, PackageTree does this

$self->do_event('curPkg changed');

The event is then passed upwards (through 'owner'). Panes gets it, then
runs the code that has been registered in its event list by MethodList,
who itself runs 'refresh'.

So far the event scheme is working well, with the events being localized
(no objects recieve the event that don't need to, save on execution time)
and have gotten to those who need them. The problem I'm contemplating now
is when packages on further branches of code want to use events. I'm
fairly sure the method I'm doing will work, which is to force any chains
of events that go down the tree to be explicit.

For instance, when a new method is clicked in MethodList a 'curMethod
changed' event is issued. In order for the Code package to know of the
event, and thus change what method is being displayed, its owner, Editor,
must register the event with Browser, and then issue its own event. In
order to use this backwards-flowing chain eficciently I created the
do_local_event method (in the Browser::Base package, along with the other
event stuff) so events would then not escape upwards without reason to.

How does this scheme sound to you? The only alternative I thought of was a
global event list, but I don't like global things. On the other hand, a
global event list might be simpler. The other thing to consider is the
order in which events get called back. Right now packages that are closer
to where the event takes place know about it before ones that are far
away, whereas in the Global List it would be very first-declaired
first-served.

--Brock