Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Sep 16, 2003 at 11:11:56AM +0200, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | 5. use buildCursor().dispatch() instead of getLyXText()->dispatch() in
>> | the default branch of BufferView::Pimpl::dispatch() [That's the fun part
>> | but should not be that hard]
>>
>> Well... I have my own plans for distpatch...
>
| Haven't seen them so far ;-)
:-) Has been mentioned in bits and pieces over the years...
>> My take on this is that we should always enter the "distpatch-tree"
>> from the same point.
>
| Exactly. But there are two entry points: current cursor and (x,y)
| coordinate.
Yes, but they should use the same entry point to the dispatch
machinery.
>> IMHO the "master" dispatch should handle the fanning out.
>
| That's the GlobalCursor::dispatch, which goes from the leave (i.e. the
| innermost inset) up to the root (the main lyxtext or buffer) and ask
| each inset on that way up whether it is willing to handle the
| funcrequest. If it does, fine, if not, the parent is asked. Exactly the
| same as MathCursor::dispatch does.
This is just the opposite way as to what I imagine.
(if implemented down->top that is... I had a recusive decent with a
roll-back in mind.)
>> I am not sure how this will interfere with your work.
>
| I'd guess you'd end up with pretty much the same scheme. There seems to
| be only one 'canonical' way to implement it once we've settled on the
| 'inside->outside' strategy.
This is what I am not sure about... I also have a idea of a "distpatch
domain" so that we can register lfuns, and not have gigantic static
switches as we have today.
>> Master dispatch to me is LyXView::dispatch... this one should send
>> down to BufferView::dispatch and further on to LyXText::dispatch or
>> Inset::dispatch.
>
| Fine with me. The scope of what you want is even larger but there is
| no reason why the GlobalCursor can't have a 'bottom slice' handling the
| View dispatch. For the innards (i.e. dispatching in the LyXText tree)
| you will need something like my proposed GlobalCursor::dispatch anyway,
| so if the two things are not completely identical they are
| complementary.
Might be true, yes.
>> Why I want this?
>>
>> I'd like to have one dispatch exit path, so that some operations could
>> be done there and not be spread out all over, in particular update and
>> fitcursor.
>
| Same here.
>
>> | 6. Simplify the structure of InsetText::localDispatch by removing most
>> | of the special RESULT handling (locking and unlocking is done in the
>> | GlobalCursor::dispatch). The result should be just a big switch.
>>
>> And I am trying to get rid of the big switch.
>
| How should that work?
Mentioned it above. Registrations of LFUNS with dispatch domains.
In essence we could do with only one dispatch functions that lookup
the domain to see if that can handle the function asked for. So you'll
have a tree of domains (inner->outer)
| [Note that individual LFUN handler functions are a pain in the ass. I
| had this once working in mathed and it required much more typing,
| recompilation time and general hand holding than the big switch. Most
| notably, adding a new LFUN specific to a single inset or two meant
| recompilation of the whole tree. The big switch is certainly not
| 'Nice', but works and is easily maintained once there is nothing more
| than the big switch in dispatch(). But I guess you won't accept that
| until you tried that by yourself...]
I belive my approach is a bit different, since it is a lot more
dynamic. In my approach the dispatch machinery will not even know of
the function at compile time. Registration will be done at run-time.
>> | [7. Try to let InsetText::localDispatch use LyXText::dispatch in
>> almost | all cases]
>>
>> We should also rename InsetText::localDispatch to just
>> InsetText::dispatch
>
| Spare me the cosmetics in the planning phase ;-}
it is just annoying to have all those strange names...
cosmetics matter.
| [Btw, last time I proposed to rename all localDispatch's to dispatch
| you opposed the idea...]
I did? how stupid of me.
>> My take is that we should at least make some effort to fix some of
>> those regressions before beginning to shift things around again, and
>> to introduce new regressions.
>
| I won't stop you ;-)
I have at least fixed one regression...
--
Lgb
