On Tue, Sep 16, 2003 at 11:45:41AM +0200, Lars Gullik Bjønnes wrote: > >> 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.
LyXView as it currently is and will be even after your scheme that entry point. That's fine as that's the place where the 'user events' emerge. > >> 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. Huh? But that's what we have now and that's what makes most sense: The innermost inset should have the first chance to handle some event, than its parent and so on. Are you suggesting something else? How one reaches this innermost inset (i.e. either by feeding the event directly to the tip of the stack of cursor slices or by moving up slice by slice until the tip is reached, is secondary. Although I'd argue that given a stack, accessing the proper end directly instead of going to the 'wrong end' and traversing makes a bit more sense...) > | 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. We can have a look at 'lfun registering' once we have straighten out the over all structure. [As I said, I have certain bad experiences with that for LyX although it usually works fine in my own stuff, but I accept that you want to get to this point yourself]. But you do agree that registering only works as replacement of a big switch but not as a replacement of a switch with additional bits of logic sprinkled over it, don't you? > >> 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. Good. > >> 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. I am all for trying it out. > 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. So the handlers are not polymorphical in the inset, but rather stand-alone 'minifunctions' in the .C? This would remove the recompilation and the 'lots of symbols' problem, so this should be feasible. Ok... I even think I like it. In any case, this would require to get rid of the locking as well, wouldn't it. So it could (and probably has to) go on top of the locking changes, and at least for a transitional phase according to my scheme we'd probably need the global cursor. [Well, it took me a while to come up with the transition scheme, even if it looks simple in hindsight. Maybe there is a direct transition scheme to what you propose...] > >> 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... And I've introduced much more than that... 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...)
