On 03-Dec-2001 John Levon wrote:
> yes, for example insetgraphics that have finished rendering (which is what
> the bug fixes ;)
Well let's say what the bug fixes in some really special case: the requested
graphics inset is exacly INSIDE bv->theLockingInset() (not inside an inset
of bv->theLockingInset()) and I can think of a lot more cases then this one ;)
> I don't understand why we have :
> inset->updateInset(some_other_inset)
> AND
> inset->updateInsetInInset(some_other_inset)
> but that's just an implementation detail I think. I would prefer just to
> hand off updateInset(some) to the locking inset and have done.
#:O) well I really had to smile with the above code. See we call the
function updateInsetInInset(some_other_inset) because it's just what it
does. You can also call it updateInset(some_other_inset), but IMO that the
actual name actually does tell us better what we do there!
Maybe you confuse BufferView::updateInset with UpdatableInset::updateInsetInInset.
Could that be?
> 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
Yep!
> I don't think so. An inset does not know which inset contains it.
Nope! It knows about it as we have Inset * Inset::owner() which returns
0 for top-level-insets and the containing insets for insets down the tree.
But this has nothing to do with theLockingInset-mechanism!
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
I remember Ulysses well... Left one day for the post office to mail a letter,
met a blonde named Circe on the streetcar, and didn't come back for 20 years.
