On Wed, Jul 31, 2002 at 08:03:51PM +0200, Andre Poenitz wrote:
> > except we don't replicate the code for a map in each inset.
>
> There would be one map<action, callback> _per class_. That's not
> expensive.
OK, so basically you're devolving one level of the two-level
action->handler map into the inset class. Hmm.
Not sure how that would work out. For one thing the inset classes are
way too big already.
> Actually I don't think the approaches are too different. You have some
> sort
> of "global intelligence" which figures out which insets needs to be
> asked,
> my approach is just a bit more localized: One loop of potential
> receivers
> and the "intelligence" is in the inset. The code actually goes into
> the
> inset base and the derived insets only register their handlers. That's
> fairly minimal I think.
But what intelligence is there anyway ? None really, other than the
override thing ...
> Well. In general we draw a screenful as response to an 'a'. Insets are
> nested ... 10 levels? So this is 10 function calls?
Yeah, not a big deal
> [This inset locking stuff should go ASAP IMNSHO]
Sure, but I'd love to see you handling the contained inset stuff :)
> In my version an inset would simply shrink the cursor by one level in
> this
> case and let the "Right" action intact. Then the parent of the inset
> sees
> the "Right" action and does its thing...
Right. Analgous but probably a lot cleaner. Until we find all the
painful special cases. In many ways this stuff goes hand in hand with
your plans.
> Okokok. Then get the "small things" right and I won't complain.
Well I'm not sure it's worth expending effort on code I'm not sure is
workable or a good idea
regards
john
