Jean-Marc Lasgouttes <lasgouttes <at> lyx.org> writes: > PainterInfo is defined in src/MetricsInfo.h. "git grep" is your friend > to find this kind of information.
Thank you. Got it. > > Did you notice > > that the size of the vertical scroll bar changes when we come into the too > > wide math equation, from another row? I do not think that is not a bug > > appeared at this moment. But as I can see it came from the previous > > versions. I have no idea why that is happening. > > 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. > > *fixing the wrong sliding when entering from either right or left corner of > > a Math inset. > > This should be fixed by invoking some rp.paintXXX as I mentionned in a > previous set of messages. Do you remember them? I suspect that a > > pi.pain.setDrawingEnable(false); > rp.drawOnlyInsets(...); > pi.pain.setDrawingEnabled(inside && original_drawing_state); > > call before doing our left_edge computations should do the trick. Do you > see what I mean? 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. 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, "When you get this abnormal position, try to move the MOUSE (mouse pointer; not the text cursor) without any key or mouse press. Try to move the mouse pointer up and down such that the pointer passes our Math inset. At some point, the text cursor automatically updated to our expected position (without any key or mouse press)." Also I believe if we call that when sliding happens, this problem and also the following problem will get solved. But I have no idea, what happened when only the mouse pointer moves. I tried to do a search, but I was not able to get any idea. Could you please explain more about how this will be fixed with your suggestion? > > *fixing the wrong sliding happens when selecting positions or range of text > > in a too wide row using mouse pointer/ cursor. (related to the above problem) > > You need to take left_edge in account in target_x computations. I > suspect that target_x should reflect the visible on-screen position > (after scrolling) rather than the logical one (without scrolling). > > > *implement the sliding needed when using Home/End keys. > > 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. That moves to the end of the line, but we can't dee it as the row is not sliding there. But again if you move the mouse pointer over the Math inset, that will automatically slide to the end of the line? Is what you have said, the solution for the above mentioned problem? Is not TextMetrics:draw called for each and every key stroke? Thank you Hashini
