Re: [Abook-devel] scrolling

[R. D. <rap...@gm...>]

On Sat, May 12, 2012 at 04:23:00PM +0200, Thorsten Wißmann wrote:
> The only strange thing is scrolling, because it just moves the selected
> line-marker instead of really scrolling the list (like it is known from
> vim, ncmpcpp or real gui-applications). You'll find a patch
> 0001-Scroll-whole-list-on-mouse-wheel-action.patch attached that let's
> the actual whole list scroll.
> 
> I didn't push it to my repository because the names of the new functions
> and maybe even its behaviour is worth discussing. What's your opinion
> about these two points?
> 
> Thorsten

Hi,

I do agree on the fact that a _nice_ scrolling solution is
desirable but mainly two of them are really useful:
* scroll by X lines when you're about (1 line) the reach an edge
or
* scroll by 1 line when you're 2 or 3 lines from an edge (= always
keeps 2 or 3 lines of "context")

The later is more or less what wscrl curs_scroll(3) may ease.
But then it would be up to abook to redraw the needed areas *only*
(it currently unconditionally redraw the whole list)

Painting only parts of the list seems a bit more challenging; the
attached path is a (broken) attempt to do this
( to use with ./abook 2>|/tmp/err.log )


You're patch use a different solution which is not the best (but it may
only be a question of personal taste), anyway there's a problem:
if you make the viewport scroll down once, then you have no ability to
scroll up to the top-most entries anymore.
But your patch  is far more simple and even adds an option. So I think
the best thing, *if the wscrl solution is a dead-end*, may be:

* use your patch as base (relying on a non-altered refresh_list())
* if possible, make the scrolling based on the "context", ie: scroll the
  viewport if the selected entry is near of the window extremity, in
  order to always keep some lines of context.
* to not make the context (speed) an option, it would clutter the
  configuration for a feature which can easily be given a sane default
  setting (probably between 2 and 5 lines)


As a last point, thinking further about scrolling, I would really like to
find a way to disable ncurses wheel support if the terminal handles this
internally because scrolling is then far more responsive.
Some gtk/qt terminals (and newest version of urxvt) handle this: they
roughly simulate the key-up (eg you can scroll "natively" in `less`)
ncurses wheel handling stays useful for Xterm and linux console (though I
don't about gpm wheel capabilities)



regards