On Sun, Mar 06, 2005 at 05:31:47PM +0000, John Levon wrote: > On Wed, Mar 02, 2005 at 07:23:10AM +0100, Kornelia Poenitz wrote: > > > Theree is a strange phenomenon that a click in the right hand half > > of an inset does not seem to count as click in the inset bu places > > the cursor behind that inset. I think I have seen this in ERT, too, > > Argh! The dreaded bug is back! I assume this is probably completely > different cause from the 1.2.x era cases though :) > > john
I did some research into this bug, leading to the following results:
1) The bug occurs only in math (not ERT). It requires an inset inside an
inset.
2) The villain seems to be getCursorPos ("This is a hack") in
math_nestinset.C:
121 x = pt.x_ - pt2.x_ + ar.pos2x(sl.pos());
What happens here is, that the absolute x (in pt) is made relative by
subtracting the inset's reference position (in pt2), and then taking
into account the character position within the inset.
The problem occurs if there is an outer and an inner inset. Then, this
method is called for both, and the results are apparently tallied up
somewhere when the absolute cursor position is reconstructed.
For the outer inset, this is wrong. The problem is, that in this case
one of the "characters" is the inner inset. If you click on the
rightmost half of this inner inset, the cursor will fall to the right of
it, sl.pos() will be 1 and ar.pos2x(sl.pos()) will return the inner
inset's width. Which is wrong, as the inner inset will still add to this
the cursor offset within it... *from its left edge*.
What *should* happen is, that if sl is not the tip of the cursor stack,
the term ar.pos2x(sl.pos()) should not be added. Like this:
if (sl == cur.top()) {
x = pt.x_ - pt2.x_ + ar.pos2x(sl.pos());
else
x = pt.x_ - pt2.x_;
Unfortunately we do not have cur inside this method.
Any good suggestions anyone?
- Martin
pgp1owqsPF0ET.pgp
Description: PGP signature
