On Fri, Mar 21, 2003 at 10:34:13AM +0100, Juergen Vigna wrote: > Andre Poenitz wrote: > >So why do we see several updates per redraw? > > > >Why does an inset communicate explicitly with its parent? > > I think discussing helps thinking ;)
[Pretty unconventional approach nowadays. It seems that solving disputes by throwing a few bombs and killing a few people is becoming popular...] > The problem we have is that we do "updating" of the text in "rows". > so if the "inset" is embedded in a row and it changes it may be that > we have to recalculate the whole row (therefore up and down). Yes. We have nested containers in several levels. > I don't see any easy solution for this as we cannot "update" first > all insets and then the text, as we then don't know the exact "x" > position of the inset and this gives us the "width" of the inset. Hah! The point is, the first phase fixes only the _size_, not the position. The position is not relevant for the computation of the size of the parent. At the end of the first phase everybody knows its size, but not its position. The actual positions are determined during the second phase. They would not even have to be stored if we had not to support mouse clicks or LFUN_SET_XY. > Why not let us create a branch and try out the solution to update > all insets first (starting from the innermost childs!) and then update > the text structure. After that doing the draw. And see what's happens. > > I won't do something like this in the main branch. Well, I am still not too fond of branches... but ok. I won't be able to spend any time on it during the next three weeks, though (first some conference and than a few days off...) > And maybe it comes back to my mind what examples I had which did break > this behaviour. That would be indeed interesting. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
