On Mon, Dec 03, 2001 at 02:47:28PM +0000, John Levon wrote: > On Mon, Dec 03, 2001 at 03:38:18PM +0100, Andre Poenitz wrote: > > Does anything needs this kind of focus that is _not_ in immediate > > neighbourhood of the cursor? > > yes, for example insetgraphics that have finished rendering (which is what > the bug fixes ;)
I see. > > If so, why isn't the cursor used for such things? > > that would require each cursor to know not only its container, but the tree > of containers... No, that would require the cursor being a representation of the _path_ from the tree root to the current position. Sort of a stack: push inset when entering an inset, pop when leaving one. The "actual position" is the top of the stack. If inset manipulation happens near the cursor the insets themselves do not have to know there parent, they could ask the cursor instead. > I don't understand why we have : > > inset->updateInset(some_other_inset) > > AND > > inset->updateInsetInInset(some_other_inset) I have not even understood what updateInset and updateInsetInInset are supposed to do. > nope, bv->theLockInset() is always the top-level locked inset (I think). > The chain of inset->the_locking_inset has to be follwoed to get to the current > active locked inset Is the "full text" an inset? > > ... and introduces some kind of "back reference" which is usually a pain to > > maintain and to get right? > > I don't think so. An inset does not know which inset contains it. So what are all these 'onwer_' pointers used for? Andre' -- André Pönitz .............................................. [EMAIL PROTECTED]
