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: Thu, 03 Apr 2003 05:38:02 -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> <3E8345E8.4090509@swipnet.se> <1048872463.17161.132.camel@localhost.localdomain> <1049134327.3326.74.camel@localhost.localdomain> <200304021352.h32DqLO11793@eel.dms.auburn.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1049367256 28436 80.91.224.249 (3 Apr 2003 10:54:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 3 Apr 2003 10:54:16 +0000 (UTC) Cc: kai.grossjohann@gmx.net Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Apr 03 12:54:14 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 1912MI-0007OT-00 for ; Thu, 03 Apr 2003 12:54:14 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 1912No-0002gE-00 for ; Thu, 03 Apr 2003 12:55:48 +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 1912GU-0001cr-03 for emacs-devel@quimby.gnus.org; Thu, 03 Apr 2003 05:48:14 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 1912G6-0001WT-00 for emacs-devel@gnu.org; Thu, 03 Apr 2003 05:47:50 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 1912G4-0001Pm-00 for emacs-devel@gnu.org; Thu, 03 Apr 2003 05:47:49 -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 1912Cr-0008A0-01 for emacs-devel@gnu.org; Thu, 03 Apr 2003 05:44:29 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.10) id 19126c-0005cH-00; Thu, 03 Apr 2003 05:38:02 -0500 Original-To: Luc Teirlinck Original-to: otaylor@redhat.com In-reply-to: <200304021352.h32DqLO11793@eel.dms.auburn.edu> (message from Luc Teirlinck on Wed, 2 Apr 2003 07:52:21 -0600 (CST)) Original-cc: emacs-devel@gnu.org 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:12866 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12866 The appearance of the GTK scrollbar was chosen to provide a metaphor for a a pixel based approach. Exact same appearance with different behavior is confusing, The same appearance with gratuitous incompatible behavior would be confusing, but handling overscrolling is an extension, not an incompatibility. No matter how the GTK scroll bar handles overscrolling, this will be an extension to the usual scroll bar behavior. It cannot be 100% compatible, but it can be more compatible or less compatible. Handling overscrolling the native scroll bar way, by virtually moving the thumb "out of" the trough, is mostly compatible with the normal behavior, because it results in the same visual appearance for the scroll bar for all the non-overscrolled cases. If you don't overscroll, everything looks normal. Handling overscrolling in the current Motif way, by treating the maximally overscrolled position as "the end", is incompatible in user terms, because the same scroll position in the buffer corresponds to a different appearance of the scroll bar. I indeed have trouble finding other applications that allow overscrolling. But it is clear that there are people who wish that there were more applications that would. If an application with a pixel based philosophy decides to allow overscrolling, it is likely that it would want the scrollbar to behave in the way I described PixelStuff's scrollbar. If an app with pixel-based scrolling supports overscrolling, I think it should display the overscrolling just as Emacs should, by having the thumb virtually move beyond the end of the trough. Visually, the overscrolled piece is a piece of the "document" that you can scroll to. Even for pixel-based apps, I don't think this is a good way to look at the issue. > 3. Make the GTK scrollbar more customizable so that it can optionally > handle a character based approach and hence behave, within Emacs, > more like the native scrollbar than the pixel based variant of the > GTK scrollbar. I think this is the only reasonable solution. I agree with Miles--this is the only right way. Owen, would you please implement this facility in the GTK scroll bar?