From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: kai.grossjohann@gmx.net (Kai =?iso-8859-1?q?Gro=DFjohann?=) Newsgroups: gmane.emacs.devel Subject: Re: Gtk scrollbar: thumb too short Date: Fri, 11 Apr 2003 16:02:20 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <844r55f7yr.fsf@lucy.is.informatik.uni-duisburg.de> References: <200304111308.h3BD8oW03188@eel.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1050070892 32499 80.91.224.249 (11 Apr 2003 14:21:32 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 11 Apr 2003 14:21:32 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Apr 11 16:21:25 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 193zOj-0008Ot-00 for ; Fri, 11 Apr 2003 16:20:57 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 193zUD-00055Z-00 for ; Fri, 11 Apr 2003 16:26:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 193zIo-0001wA-00 for emacs-devel@quimby.gnus.org; Fri, 11 Apr 2003 10:14:50 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 193zEj-0000ul-00 for emacs-devel@gnu.org; Fri, 11 Apr 2003 10:10:37 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 193zBc-0007c4-00 for emacs-devel@gnu.org; Fri, 11 Apr 2003 10:07:25 -0400 Original-Received: from mailout09.sul.t-online.com ([194.25.134.84]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 193z91-0006aN-00; Fri, 11 Apr 2003 10:04:43 -0400 Original-Received: from fwd05.sul.t-online.de by mailout09.sul.t-online.com with smtp id 193z8q-00065c-00; Fri, 11 Apr 2003 16:04:32 +0200 Original-Received: from lucy (520080024987-0001@[217.225.230.94]) by fmrl05.sul.t-online.com with esmtp id 193z8g-0DEXwGC; Fri, 11 Apr 2003 16:04:22 +0200 Original-Received: by lucy (Postfix, from userid 1003) id E6A0728859; Fri, 11 Apr 2003 16:02:20 +0200 (CEST) Original-To: Luc Teirlinck In-Reply-To: <200304111308.h3BD8oW03188@eel.dms.auburn.edu> (Luc Teirlinck's message of "Fri, 11 Apr 2003 08:08:50 -0500 (CDT)") User-Agent: Gnus/5.090018 (Oort Gnus v0.18) Emacs/21.3.50 (gnu/linux) X-Sender: 520080024987-0001@t-dialin.net Original-cc: rms@gnu.org Original-cc: jan.h.d@swipnet.se Original-cc: otaylor@redhat.com X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:13154 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13154 Luc Teirlinck 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)