On Wed, Nov 03, 2004 at 03:24:00PM +0100, Alfredo Braunstein wrote:
> Jean-Marc Lasgouttes wrote:
>
> > Alfredo> Btw, I didn't appreciate at all that you have *removed*
> > Alfredo> fitCursor and friends. The fact that fitCursor isn't used in
> > Alfredo> this version is a consequence of the limitations of this
> > Alfredo> approach, but we certainly need it in the final version.
> >
> > From what I remember, removing fitCursor was an integral part of the
>
> Honestly, I think this would be nonsense. fitCursor has a 1-to-1
> correspondence with a concrete feature. I think that André had always
> cursor-follows-scrollbar and simple ignored (or forgot) the other case.
I did forget it. However, the primary source of y position does not have
to be the Cursor, a paragraph index in the outer inset + some small y
offset for smoother scroll would do as well. And this could well be
derived (i.e. approximated) from
This paragraph inset + small y poffset is more or less equivalent to
Alfredos anchor row but does not depend on _row_ infomation. The idea
is really to make the row cache a _cache_, i.e. something that helps to
speed up things but which is technically not required.
Cursor down would than simply leave the (pit, yoffset) untouched as long
as the cursor stays on screen. When the cursor goes further down, the
yoffset is adjusted until a full paragraph have scrolled off the screen.
Than the pit is incremented an yoffset -= paragraphs_[pit].height().
Same for 'up'.
When scrolling with the scrollbar and non-following cursor we
approximate a (pit, yoffset) pair from the slider position.
Say slider gives something in the range [0..1], we'd use
pit = int(pars.size() * slider)
yoffset = (pars.size() * slider - pit) * pars[pit].height()
[or similar +/- one]
> > plan. I guess Andre has ideas on how to remove the limitations...
>
> Note that the limitations have little to do with fitCursor (except
> the fact that with the limitations, the cursor is always on screen so
> fitCursor is noop) Well if he/you have, it would be a good moment to
> discuss it. In fact I've started this discussion before
> (http://marc.theaimsgroup.com/?l=lyx-devel&m=109614325020341&w=2), but
> nobody answered.
>
> I think that we need:
>
> - another document iterator in bv ("anchor") - an y offset
The anchor should be pit in main text + y offset. Idea is to keep the
y offset small as this is the range in which we need exact y
information, i.e. the range in which paragraphs need to be rebroken.
> the anchor would point to the first document position appearing on
> screen (or even the outermost paragraph of that position), and the y
> offset would be wrt to that position.
Exactly.
> On draw, we would draw from the anchor down until we reach screen
> height + offset pixels on the back pixmap, and then position the
> screen on offset.
I wouldn't care too much about the back pixmap but just recreate it on
draw similar as currently implemented: start with par at anchor position
rebreak it, go down with rebreaking more pars until the lower scren edge
is hit. Then draw these pars into the pixmap and bitBlt to screen. Or
similar.
> Of course, both need to be kept on-sync.
Rebreaking a screenful of pars is sufficiently fast. No need to
complicate matters here.
> Does this sound reasonable?
Sort of, yes.
Andre'
