Re: [Abook-devel] scrolling

[Thorsten W. <ed...@th...>]

On Thu, May 17, 2012 at 08:34:50PM +0200, Raphaël Droz wrote:
> 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?
> 
> 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")

I think this context isn't really needed in abook. It is e.g. in vim
where the meaning of a line may depend on the previous or following
lines. But the address book entries are more or less independent from
each other. Of course I can implement it, even if this scroll context
just "looks nice".

> 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 )

In my opinion it is to much work to rebuild this with wscrl, because the
abstract design of any curses program should be:

    Input (window size, mouse actions, ...) affects:
    Internal state (scroll offset, selected line, ...) affects:
    the window buffer

If you use curs_scroll you'd only manipulate the window buffer but you
still have to maintain the internal state, so i suggest to always fully
repaint the window from the internal state: It works better (e.g.
doesn't break on the window resize) and is less code. (So in my opinion
the wscrl is a dead-end)

> You're patch use a different solution which is not the best (but it may
> only be a question of personal taste),

Is it the structure of the code or naming of the variables or anything
else?

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

Of course you can scroll up until you see the top-most entry. You just
can't select it by just using scroll up/down actions.

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

That should be possible. So it is basically what scrolloff in vim does.

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

IMO the context size and the scroll speed are two completely independent
(and so completely independent configurable) options.

> 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)

Currently I don't know how to just disable scrolling. (Just don't
listening to BUTTON_{4,5} doesn't work). But if it would simulate
key_up/down, then it wouldn't be the same, because scrolling (i.e.
moving the viewport) is a really different behaviour from moving the
selection (which is the effect of key_up/key_down).

Thorsten