From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Gtk scrollbar: thumb too short Date: Sat, 29 Mar 2003 13:38:45 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20030325193739.ZGIN3924.fep01-svc.swip.net@gaffa.gaia.swipnet.se> <1048780121.14517.22.camel@localhost.localdomain> <200303271630.h2RGU1bT028651@rum.cs.yale.edu> <1048799271.15136.69.camel@localhost.localdomain> <200303272142.PAA27945@eel.dms.auburn.edu> <1048801290.15149.88.camel@localhost.localdomain> <1048825714.16262.8.camel@localhost.localdomain> <200303280607.AAA28306@eel.dms.auburn.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1048963266 19560 80.91.224.249 (29 Mar 2003 18:41:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 29 Mar 2003 18:41:06 +0000 (UTC) Cc: monnier+gnu/emacs@rum.cs.yale.edu Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat Mar 29 19:41:04 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 18zLFt-00054V-00 for ; Sat, 29 Mar 2003 19:40:37 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18zLIr-0003n7-00 for ; Sat, 29 Mar 2003 19:43:41 +0100 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 18zLF3-0003YU-03 for emacs-devel@quimby.gnus.org; Sat, 29 Mar 2003 13:39:45 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18zLEK-0002iy-00 for emacs-devel@gnu.org; Sat, 29 Mar 2003 13:39:00 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18zLEI-0002hk-00 for emacs-devel@gnu.org; Sat, 29 Mar 2003 13:38:58 -0500 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.10.13) id 18zLE6-0002OE-00 for emacs-devel@gnu.org; Sat, 29 Mar 2003 13:38:46 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.10) id 18zLE5-0001wU-00; Sat, 29 Mar 2003 13:38:45 -0500 Original-To: Luc Teirlinck In-reply-to: <200303280607.AAA28306@eel.dms.auburn.edu> (message from Luc Teirlinck on Fri, 28 Mar 2003 00:07:58 -0600 (CST)) Original-cc: jan.h.d@swipnet.se Original-cc: kai.grossjohann@uni-duisburg.de Original-cc: jody@gnome.org Original-cc: emacs-devel@gnu.org 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:12743 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12743 Bug or feature? I do not know whether there is a "correct" answer to that question. It depends on what the user is trying to do and on the user's taste and expectations. I think we should consider it a feature. Consider outline mode, for instance. I think it is correct that the scroll bar indicates the amount of total text in the area displayed, including the hidden parts of the outline. In other words, what the thumb seems to measure is the proportion of total (visible or invisible) text between top and bottom of the screen compared to the total text in the buffer. This seems to be the behavior in Emacs 20.7 with native scrollbars, as well as in the current 21.3.50 CVS, both with native (./configure --without-toolkit-scroll-bars) and with Xaw3d (no options to configure) scroll bars. That is the way it should work. Basically, the scrollbar should be based on "number of vertical pixels" rather than "number of chars", but given the current way Emacs is written, it's basically impossible to do. Basing it on pixels would be consistent behavior, but (as you said) it isn't feasible. For Emacs to do this computation for the whole of a long buffer would take much too long. 3) Updating thumb size while dragging That just seems irritating. If a user selcts the bottom of a large thumb at the start of the drag then the thumb shrinks they end up in an odd position. This seems to be a case where all alternatives are flawed. I agree that changing the thumb size while dragging would look strange--but if you don't change the thumb size while dragging, it has to change when you stop dragging, and that would look strange. I don't yet have an opinion about which one is better.