emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gtk scrollbar: thumb too short


From: Kai Großjohann
Subject: Re: Gtk scrollbar: thumb too short
Date: Fri, 11 Apr 2003 16:02:20 +0200
User-agent: Gnus/5.090018 (Oort Gnus v0.18) Emacs/21.3.50 (gnu/linux)

Luc Teirlinck <address@hidden> writes:

> There is some "precision work" required, no doubt about that.  You
> have to drag slowly and carefully, you can not just "yank".

Dragging the thumb to the beginning of the buffer does not require
precision work.  So it would be nice if it wouldn't require precision
work for dragging to the end of the buffer, either.

Ideas:

* Some window managers offer "attraction" or "resistance".  Attraction
  means: when one window edge gets close to another window's edge or
  to the edge of the screen, the window is warped so that the two
  edges are adjacent.  Resistance means: when one window edge becomes
  adjacent to another window edge or the edge of the screen, moving
  the mouse further by a few pixels does not move the window.  One has
  to move the mouse several pixels before the window starts moving
  again.

  This could be adapted to the end of buffer condition: you drag the
  thumb downwards.  As soon as end of buffer becomes visible, dragging
  the mouse down by a few more pixels doesn't change the buffer
  (thumb) position.  You have to move the mouse down a minimum number
  of pixels to make the thumb move again.

  Mouse pointer and thumb could become out of sync, as the mouse
  pointer moves down without the thumb moving.  The visual
  inconsistency might be bad.  For a window near the bottom of the
  screen, this could become a functional problem, even.

  Window managers often solve this by moving the window "a lot" when
  attraction/resistance is overcome.  For example, let's say the
  resistance is 10 pixels, then moving a window 1, 2, ..., 10 pixels
  offscreen is not possible, the minimum number of pixels to move it
  offscreen is 10.  Alas, this solution does not seem feasible with
  the scrollbar since there is not much left to scroll after end of
  buffer becomes visible.

* If end of buffer is not visible when scrolling-by-dragging starts,
  then overscrolling is not possible.  Only if end of buffer is
  visible when scrolling-by-dragging starts, then overscrolling
  becomes possible.

  Users have to drag twice to achieve overscrolling.  A potential
  problem with this approach occurs when the thumb warps to the
  position of the mouse pointer when dragging starts, as it happens
  for the native scrollbar.  Then users would have to hit the right
  spot on the thumb to ensure that end of buffer remains visible when
  scrolling starts.  But I think that this problem does not occur
  with the Motif and Gtk scrollbars; there it does not matter where
  exactly one hits the thumb when starting to drag-scroll.  Am I
  wrong?

What do people think?
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]