On Wed, Jul 10, 2002 at 10:05:22AM +0200, Juergen Vigna wrote: > >When mathed currently gets a click, the cursor is positioned as close as > >possible and the event is passed up along the cursor path until some inset > >is willing to handle it. > > I'm confused now in your former mail you said it works from the > innermost one to the outermost and now you are telling me that it's > exactly the opposite.
I am not. The event is passed _up_ along the cursor path. > >Yes, that's exactly the opposite as it works outside but that means that > >insets only have to be aware of events they want do handle and simply > >ignore the rest, whereas "oustside" every inset has to pass down all > >"unknown events". > > I don't understand this claim and I don't believe it. Can you please > explain this for dummies like me and maybe make a real-world example so > that I'm able to follow what you mean. The big Dispatch in lyxfunc.C has to pass (-- or, I don't know whether it _has to_, but it certainly does --) math related LFUNs (as 'math-extern' for example) to a math inset. So it is aware of the fact that math insets might handle 'math-extern'. Why should the dispatcher (a) know of the existence of math insets (or any other inset for that matter) and (b) explicitly know which events are handled by that inset. > Well I think most stuff is solvable so we think the same here :) > > >pre-alpha code for a \parbox implementation that would exactly do that. > >But this is far from finished, so mathed is currently no replacement for > >InsetText. > > \parbox is very different as it too has a "fixed" size doesn't it? It has. But how is that different from a fixed width of the main LyX screen? > >Bottom up along some iterator which in most cases is the one > >representing the cursor position in *mathcursor. > > What happens if you don't have a cursor? I mean what handles if I have > size changes and no cursor inside the mathed inset (think of undo!) Gosh. _Any_ iterator will do. That's currently the cursor in most cases is just co-incidence and/or bad separation of functionality. > Well that's the same in all insets (see the handle of pre_events in > insettabular), but most events have to pass the innermost InsetText as we > don't know if it wants to handle it or not. The events just have to bubble up and the innermost text inset will shout "Hey, I can handle that!" Anyway. I have made my mind up. If we want 1.3 out in September or so, I won't do something concerning the inset unification that touches the "outer world" i.e. src/inset as well as the core. I'll just try t get the math insets and cursor right and then we'll have something to mumble about in the 1.4 cycle. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
