On Wed, Jul 31, 2002 at 07:42:02PM +0200, Andre Poenitz wrote:
> > Eventually this will remove the total inclusion of commandtags.h, allow
> > more fine-grained dynamic contexts, and more
>
> Fine. I just wonder whether this mechanism is not too complicated.
>
> Each type of inset could have a class-static map<action, callback> [This
> is the "one function handles one action"]
>
> Let's assume we have an easy way do go from a cursor or mouse click
> position up the hierarchy of insets. Each inset is asked whether it want to
> handle (or modify(?)) the action. If someone answer "DONE", we are done.
But this is what happens in the patch, except we don't replicate the
code for a map in each inset. Rather an inset expresses an interest in
an action, and receives it when it's fired. It should NOT be receiving
any lfun it has no interest in (why ?)
The difference is we do this searching once "statically" by means of the
registration, and you're suggesting we do this dynamically. I don't
think the few cases where we really want dynamic dispatch target finding
is worth doing it every time somebody presses 'a'
Note the post-action thing is used for "well I said I wanted the event,
but I need some clean up". This can deal with both UNDISPATCHED (if
needed) and unlocking (after cursor-right at edge of inset etc.)
> I would not think that we'd need more than 100 or 200 lines for that
> mechanism.
action.C is 182 lines and has a centralized position for all the
dispatch handling ...
thanks
john
--
"The simpler it is, the harder it is."
- Tim Van Holder
