Le 24/08/2013 19:11, Hashini Senaratne a écrit :
I have no idea either. You should maybe chack what happens with normal
LyX on a normal file. I am surprised that we could have changed that.
I am not just talking about the size. Of course size is getting reduced, due
to the appearing math item bar at the bottom. Sorry I have not mentioned
about it clearly. When using the vertical scroll bar to reach the bottom of
the document, it gives a wired behaviour (floating up and down) and it is
impossible to reach the bottom using the scroll bar. But it is ok, when
using down arrow keys to reach the bottom.
I am not sure that I see what you mean, so let's keep this particular
problem for later.
It seems to me, I have not clearly understood this matter till now. I doubt
how we can call rp.drawOnlyInsets(...); before left_edge computations, as we
are only creating the RowPainter object after those calculations.
See my other message, you should be able to create another RowPainter
object.
I still believe that there is some kind of a refreshing method called when
the mouse pointer is moving over a Math equation. Quoting from a past
discussion,
For some reason, a redraw event occurs when you do that, I am not sure
why. If you want to see such events, you can run LyX with "-dbg
painting" (or enable it from View>Messages).
I am confident that some variation around the code in my other mail will
do the trick.
I think the problem here is that there is some optimization in
BufferView::draw that makes that our code is not ever seen because
TextMetrics::draw is not invoked. To fix this, the only solution would
be to move all the scrolling code to BufferView::draw, as was envisioned
at some time.
As I see this is also related with the problem I mentioned above. When we
press Home key (within a too wide Math equation), truly we can see the text
cursor is moving to the front of the line. But when pressed END, text cursor
gets disappear.
I bet that debugging will tell you that no drawing occurs in this case,
probably because in BufferView::draw, update_strategy is NoScreenUpdate.
This means that it is possible to draw cursor at start of row, but not
at end of row.
What this means is that, the code that sets left edge should be moved in
its own TextMetrics method (checkCursorScroll or something) and this
method should be called before the swith() in BufferView::draw. Then, if
needed the update strategy should be changed, so that some drawing
actually takes place. Does this make sense?
Is what you have said, the solution for the above mentioned problem? Is not
TextMetrics:draw called for each and every key stroke?
This is exactly the problem, as outlined above. I hope I made myself
clear enough.
Good luck. I will be back on Aug. 31 (but will be reading mail until
then from my phone). Please do not hesitate to send messages often,
especially when things do not progress.
JMarc
