On Fri, 18 Jan 2002, Allan Rae wrote:
> I was thinking about this after having a shower and I know what the
> problem is. It's a couple of lines lower than this and should be made
> to read something like this:
>
> if (prev->next != p.row) {
> need_break_row = prev;
> p.row = 0; // this is currently p.row = prev;
> } else {
> need_break_row = p.row;
> }
>
> That's in LyXText::drawInset();
I was right that did fix it. Now the remaining rendering problems I
mention in the ChangeLog were present a week ago so are probably just
instances of long term rendering problems with insets:
* text.C (drawInset): Turned out I didn't know enough about how
rebreaking worked. This fixes most of the redraw problems. I see an
occasional cursor trail when a line is broken now and the cursor
placement can seem out by a few pixels also after a rebreak.
To trigger the cursor trail problem do this:
load testcase-174.lyx
open the minipage dialog for second minipage (RMB)
move dialog so it doesn't overlap the lyx window
set to 45% and Apply
set to 53% and Apply
set to 54% and Apply
The minipage should be moved to the second row now and there may be a
gree cursor left behind. If not repeat the last three steps a couple
of more times. I have this happen anywhere from first time to 3rd to
everytime.
The second part is present from ages ago and involves the way
the baseline (?) seems to change when insets are opened and closed.
Put the cursor before an inset, open it, put the cursor back in front
again. Does the fact the cursor is now about 4 or 5 pixels lower look
strange to you also?
##
So I'd say bug #174 can be either closed and a new one opened for
inset render errors or better yet turn this into a render problem and
add a new inset render error bug that depends on this one. Which way
do we want to do this?
It certainly isn't "critical" or "major" or a blocker anymore.
Allan. (ARRae)
