On Mon, Dec 03, 2001 at 03:38:18PM +0100, Andre Poenitz wrote:
> > An inset that is locked demands that many operations should be requested
> > of it first. For example, updates on insets.
>
> 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 ;)
> 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...
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.
> So if I look at all the insets as some kind of tree, the "interesting
> spot" is someway down a path from the root to a leaaf, and
> bv->theLockingInset() is some kind of short cut on that path?
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
> ... 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.
john
--
"Faced with the prospect of rereading this book, I would rather have
my brains ripped out by a plastic fork."
- Charles Cooper on "Business at the Speed of Thought"
