On Fri, Nov 07, 2003 at 08:46:12AM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > See attached. Basic operations on nested text insets work, tables and
> > some of the mouse related stuff is defunct but not nearly as bad as last
> > time.
> >
> > Someone willing to help me to fix that mess?
>
> I'd like to help, but I'm afraid I don't understand the assignement. ;-)
Never mind.
> > It's probably mostly making sense of the stuff in '#ifdef LOCK' and
> > replacing it with a 'modern' equivalent. (LOCK is undefined, so this is
> > a #if 0 in disguise.)
>
> For instance in this piece:
>
> > bool BufferView::lockInset(UpdatableInset * inset)
> > {
> > + return true;
> > +#ifdef LOCK
> > if (!inset)
> > return false;
> >
> > @@ -420,6 +422,7 @@ bool BufferView::lockInset(UpdatableInse
> > }
> > }
> > return false;
> > +#endif
> > }
>
> Should we find the said inset and place the Cursor inside it? Or
> "eliminating" the function as it's done is ok?
The latter and check for misbehaviour.
> Maybe we should fix the callers to not call lockInset, but place the cursor
> appropriately instead?
Indeed, that's the way to go.
> As you'll notice, I'm slightly lost.
I don't notice that.
> If I understand correctly, we want to maintain the invariant of "the locking
> path" being equal to the path stored in Cursor. With the locking stuff
> active, this works correctly. Now that you deactivate parts of the locking
> stuff, this doesn't work anymore (and moreover, cannot be checked, because
> we don't have locking anymore).
>
> Does the cursor dispatch alone works correctly?
Sort of.
The main problem are currently the mouse events and tables.
The problem with tables is that I can't make my mind up whether they
should show up as two slices of the global cursor (Table inset + 0 Text,
Cell Inset + Cell Text) or just a single one (Table inset + Cell Text)
I am currently using two slices.
> I think that we should start be eliminating "users" of the locking stuff
> (the biggest being dispatch), but leaving the locking infrastructure intact
> for checking.
That's what I did with the small steps between long shot #1 and #3. The
problem is that at a certain stage (i.e. _now_) we need to rectify the
structure of [InsetTabule|InsetText|LyXFunc]::dispatch and use a single
big switch there instead of several of them with intermediate result
handling. #3 does so for LyXFunc and InsetText but not for InsetTabular
(which is one of the reasons that InsetTabular is not ok right now)
> But maybe I understood everything upside down. ;-)
No, I think you are on the right track.
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
