Re: [Abook-devel] scrolling: viewport or cursor

[Raphaël <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.


Here's a diff on top of yours.
[ move-marker-rather-than-move-viewport-if-screen-edge.patch ]

It:
1) forbids scrolling even more if the viewport shows the last entry.
  [ so we don't lose screen space and less wheel is needed if we go up again ]
2) move the marker instead of the viewport if the viewport touch an edge
  of the list.

Please let me know if it breaks the spirit of your patch or not.
[ moving the viewport vs moving the marker ]


Other than that:
I agree that scrolling the viewport using the wheel is an enhancement.
I admit that moving the marker using the wheel is now very moderately
  handful since your previous patch we can now "click" an entry to move
  the marker rather.
... other people opinions welcomed.


let me express a tiny reserve about the patch:

The fact that the marker starts moving too if the viewport scroll more
than 1 screen makes it a bit confusing: is it really about
viewport-only, or about moving the marker too ?
That's why I wrote (thinking about a bug):
> if you make the viewport scroll down once, then you have no ability to
> scroll up to the top-most entries anymore.
... [ I should have added "using the wheel" ]

The above second point about the diff *adds* to the
move-marker/move-viewport confusion, but it tries to be more consistent:
Since the marker already moves when we page-up/page-down, wheel could
move the marker when the viewport is already at the end of the list as well.


The whole thing is really usage-dependant:

* If you mainly want to *see* entries while staying in the index view,
then moving the viewport is enough and the patch exactly matches this need.

* But if you want to enter, modify, or email, ... then moving the marker
is mostly what you'll want.

I'm one of those who will rather "do" something with entries so my personal
wheel-flavor would be "move-the-marker".
But once again, I agree your initial mouse support implementation
handles clicks what put a damper on this wheel-move-marker flavor.


Adding a word about native wheel-support, and excluding linux console
(didn't tried imwheel yet):

If we use the "shift" trick to inhibit ncurses event handling, we can
either fallback:
* on urxvt "secondary-wheel" patch (provided in gentoo) which forces
  wheel move to 3 "arrow-up|down" (hardcoded)...
* on an urxvt simple perl extension which could do the wheel-key mapping
* xterm "vt100.translations" Xresources translating wheel events to key-press.
* ... but in most cases: nothing


In the end:
* this may be a case for key-modifier (so the user is free to move the
     cursor OR the viewport while use_mouse is always "on")
* or just push your patch and rely on the ability to click rather than
     wheel to move the marker. If people want to move the marker using
     the wheel, they can tweak their terminal.


If this patch is to be pushed, I would personally:
* enable abook's mouse (thus wheel) support, using a scroll_speed of 3 or 4
* use urxvt shift-wheel emulation for key-up/down (using a perl extension)
* scrolling (abook's viewport), clicking (abook's mouse support),
  while keeping the ability to move the marker using shift + wheel (urxvt)



best regards