On Wed, Jul 10, 2002 at 09:21:59AM +0200, Juergen Vigna wrote: > Well this seems indeed VERY strange. How would you do that? As much as I > know of the structure BufferView gets the click and delegates it to the > topmost inset, which then delegates it to it's childs if necessary (click > really hit a child). I guess that as you know from the top-level-inset > with your cursor the innermost inset you could then jump from the > outermost to the innermost and then return outside could you explain a > bit better how this works in mathed, as the above explanation is not > really exact, is it ;)
It is fairly exact as it describes how it works in mathed not outside. 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. 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". > >Redraw is "always redraw everything" but uses cached sizes of nested > >stuff. I fiddled a bit with more selective redrawing and it was not too > >bad except for the macro editing, so I decided to leave it as it is for > >the time being. I have a gut feeling that this is possible anyway. > > I think here is the real difference between InsetText and Mathed. Mathed > has more or less fixed sizes while the InsetText depending on the outside > world may have to rebreak it's rows and adapt it's sizes and not only it > but has to delegate this also to all child insets as they too may change > sizes. I am aware of these problems but I think they are solvable. I have 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. > And this was the big difficuly in getting the Inset in it's now > more or less working state and this is also the main problem why we still > see that nested insets are slower to update the normal text. You have a > lot more stuff to do for which you don't care in normal text. I believe that this was not easy to get right in InsetText and I believe it won't be easy to get right in mathed. But there is no evidence that it is technically not possible. > >I don't really no what checkInsertChar() does ... ok, had a quick look. > >There are no back references from the ownees to the owner. But as the > >insertion of a char is handled by the innermost inset that claims to be > >able to handle the insertion of _a_ char, this inset can check whether > >it wants to handle _this_ char and e.g. do nothing but return a "I > >handled this" or do nothing and return a "I do not want to handle > >this". > > Well this is the same for all inset! I see no difference in the handling > here. Fine. So the both hierarchies are not too different after all. > Well maybe I don't see it so because I wrote that code and it seems > pretty easy to understand to me. For me it's much more difficult to > understand how mathed does the same stuff and how delegation works there. Bottom up along some iterator which in most cases is the one representing the cursor position in *mathcursor. > In InsetText I have a top down delegation and then a down top back > tracking. This means that I go to the innermost inset first and if that > doesn't want to handle the event I return from there always one level up > till the outermost inset. So the events are handle by the innermost inset as well. I am doing exactly the same. The only difference is that enclosing inset does not do anything at all if the event is handled by some deeper nested inset. No big deal. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
