Hello Jean-Marc, > > I tried both of the above patches that you have sent me. But nothing was > > able to solve the problem I mentioned. (When entering Math inset from right > > edge, row slides unexpectedly to the left most position.) However bellow > > code solved the above mentioned problem. > > I'll try to have a look at this problem. > > > I am sure that is no way a good solution. > > We agree :) Drawing everything twice does not sound good.
As you have said that you are not how to check this bug, I did a little screen recording. https://dl.dropboxusercontent.com/u/105510128/Bug_Entering%20Math%20Inset.webm Here you can see that the row automatically slides to the required position without any key stroke, but when the mouse pointer is moving across that row. What if I try to draw twice within the case FullScreenUpdate, when only we are drawing a scrolled too wide row? > > I am not sure where the draw method is called twice when we are sliding > > rows, in the code given by you. Could you please help? > > The place where I draw twice (to try to have cursor position right is in > checkCursorLeftEdge: > > + // Force the recomputation of inset positions > + bool const drawing = pi.pain.isDrawingEnabled(); > + pi.pain.setDrawingEnabled(false); > + // No need to care about vertical position. > + RowPainter rp(pi, bv.buffer().text(), cur.bottom().pit(), row, > bidi, 0, 0); > + rp.paintOnlyInsets(); > + pi.pain.setDrawingEnabled(drawing); > > Is this what you were looking for? Yes, but I am curious about the fact that we are calling this set of lines before we calculating the new left edge. Thank you Hashini
