On Tue, Nov 04, 2003 at 12:49:10PM +0100, Lars Gullik Bjønnes wrote: > | Suppose a user clicks on C. What should happen? > > depends really... > I guess that in most cases B should react.
Everything else would be a surprise. > A::dispatch [neston] -> B::dispatch [neston] -> > C::dispatch [unhandled] <- B::dispatch [handled] > > | [ ] nothing > | [ ] B reacts > | [ ] A reacts > > We need to traverse down through dispatch functions until we reach the > inset that received the click. if not handle we back-track until we > find one that does. > > This means in the cased of nested insets, it is the outer of these > that first reveives the click and this insets dispatch must realize > that it has a nested inset at the same coord. But's easier to build up a stack of insets at position (x,y) and go inside-out until the first inset shouts 'I can handle it!'. The effect is the same and the implementation is much simpler. > >> And if at all possible I want the "top" dispatch to be the entry point > >> for all dispatch handling. (and if at all possible this "top" dispatch > >> should be the only one to _ever_ call update.) > > > | Fine with me. Currently the canvas related part of this top dispatch is > | LCursor::dispatch, which can be merged with the View's dispatch if the > | thing is ripe. > > What do you mean by merge here? If the only change is that you get one > huge function that better leave them as two distinct functions. I just wanted to be nice and not rip your idea of having a 'top' dispatch apart... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
