On Tue, 4 Dec 2001, Juergen Vigna wrote: > On 04-Dec-2001 Juergen Vigna wrote: > > > And what if the inset-pointer changed in the meantime (Undo/Redo)?
The insets allocated memory is at the same place isn't it? Wouldn't a signal connection be sufficient? Or a table of waiting-insets and the process they are waiting for a (UNIX) signal from? > No IMO that theLockingInset() stuff is pretty good and easy. It only > goes one direction and is only there if we really enter an inset. We > could do it with the cursor, but IMO we would add complex handling not > remove it. > > While the above update has nothing to do with neighter cursor nor > theLockingInset() we just have to have a good iterator and we'll find > the inset which want's to be updated quite fast! I wrote the fastest inset finder/iterator in the universe a few years ago based on a signal. But that was overkill. > Anyway the update/redraw process has do go from the outermost inset to > the innermost inset and back again and we have this more or less already > BufferView::updateInset(inset-to-update), the theLockingInset mechanism > is IMO only a shortcut as 98% of the update stuff (or more) most probably > will occur in the spot where we're actually editing. 98%, so you agree that most stuff happens at the cursor. It seems that InsetGraphics is the only example anyone has offered > So IMO we won't need any complicated cursor as we don't have to know > the outer inset if we access the whole stuff from the right direction. > Much of the code there was written long time ago and build up on each > other. The whole Inset hierarchy has to be rethought, as I already pointed > out with my mail about the need of a ContainerInset. Sure and we are influencing how that Inset hierarchy rethink might go by discussing new ways of maintaining positions (cursors). > But as I also said before I don't see this done neighter in 1.2 nor in 1.3 > as I see other priorities. I think that this should be done after we have > GUII finished as then we also have a cleaner base to build on and redo > this old code. > > I hope we agree all that GUII should have precedence in 1.3 and that we > shouldn't wait another 3 year for the 1.3 release, but it should go out > quite fast. I don't think anyone will have a problem with this. There is no need to rush to switch to stacked cursors. The current code is sufficient for the time being. But as the inset heirarchy is rethought yet further the possibility of revising cursor operation should not be overlooked. Allan. (ARRae) I love stacks.
