Hi Hashini, > Yes, this happens because of the early return. But if we remove that we are > with the problem, that I mentioned above. What I see is, we need to paint > the too wide rows when we are moving away from them. For example, if we are > moving from the right most position of a too wide row to another row (using > arrow keys - left, up, down), the too wide row should be repainted (this is > not happening in the current implementation and need to scroll back to the > normal position). Then if we could implement your above point (2/) I think > this problem will get solved. > However, in the current implementation, if you move the mouse pointer over > that row at this particular instance, it scrolls back. > Anyway, I will try to find a solution instead of this early return.
This might not be relevant, but have you tested with a right-to-left language? "moving away" might mean the opposite there. > I have another problem. Is there a unit test framework that can be used by > the developers of LyX? Please guide me on this. If we can use some of unit > tests that would be helpful to know, if a previous fix gets corrupted due to > a newer one. This would be great. I'm very interested in unit tests for LyX. Vincent has a personal repo where he set up a unit test framework based on google tests: http://git.lyx.org/?p=developers/vfr/lyx.git;a=shortlog;h=refs/heads/tests I'm not sure if he plans to merge (maybe after 2.1 is out?). Vincent, could Hashini merge your framework in now or would that not be a good idea? Scott
