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
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Abook-devel mailing list
Abook-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/abook-devel
