Le 21/08/2013 20:59, Hashini Senaratne a écrit :
As you asked me to change the cursor that we use in TextMetrics.cpp to
non-constant by using the non-constant cursor of PainterInfo I tried to find
information about that.
'In particular in pi you have pi.bv, which is a pointer to the buffer
view. Therefore you can change the definition of cur to
Cursor & cur = pi.bv.cursor();'
But this gave compilation errors. And I could not find any class named
PainterInfo in the repository. Why is that?

PainterInfo is defined in src/MetricsInfo.h. "git grep" is your friend to find this kind of information.

However the problem is "solved" right now by the use of mutable members in Cursor. We'll see later what to do about it.

I tried your patch and that works fine when changing rows. 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.

*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?

*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.

Shall I commit that to the same folder? But I would not be able to give a
relative address directing that picture in the LyX document.

Yes, to the same folder. There should not be any problem with that.

JMarc

Reply via email to