John Levon wrote: > Paragraph granularity is the best option I think. I don't have an
Fine. > opinion on the other question since I don't understand it (I ihaven't > spent the time to ...). When the above is done well (which is not exactly the case in CVS), we have a mathematical increasing function between pixel document coordinates and values in [0,1] (or scrollbar positions). This function is not linear. I find that this is pretty much acceptable [specially since 1) we are WISIWYM and pixels don't have all this meaning anyway. 2) we have no other choice ;-) ] The problem is that all frontend handle scrollbar pgup/pgdonw and scrollbar arrows by themselves: you specify the scrollbar 'page size' and 'line size' and they just increase/decrease by that amount when clicked on the background/arrows respectively. The only interaction with the scrollbar is just that value. This is a problem for us, since for instance a pageup has different scrollbar size than a pagedown. (effect: page up don't goes up by exactly one page, pgup+pgdown don't leave you in exactly the same position etc) The solution is that we just need to receive these events separately, and don't rely on the scrollbar to handle them. > This still breaks horribly for small documents but it doesn't sound like > we have a choice. I don't find that it 'breaks horribly' but it may be a matter of taste. I'll try to post a patch soon. > Page up / page down working 100% is the biggest issue in terms of UI. > The lying scrollbar is less important. [I assume you mean scrollbar pgup/pgdown (I.e. clicking on the scrollbar background)] I agree. (even if I'm not sure we are lying, just that the meaning of the scrollbar is different) Regards, Alfredo
