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: Wed, 02 Apr 2003 04:19:18 -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> <1049218005.16657.62.camel@localhost.localdomain> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1049367134 27979 80.91.224.249 (3 Apr 2003 10:52:14 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 3 Apr 2003 10:52:14 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Apr 03 12:52:12 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 1912KK-0007H9-00 for ; Thu, 03 Apr 2003 12:52:12 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 1912Lr-0002g3-00 for ; Thu, 03 Apr 2003 12:53:47 +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 1912Hk-0002tP-07 for emacs-devel@quimby.gnus.org; Thu, 03 Apr 2003 05:49:32 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 1912GZ-0001to-00 for emacs-devel@gnu.org; Thu, 03 Apr 2003 05:48:19 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 1912F6-0000vv-00 for emacs-devel@gnu.org; Thu, 03 Apr 2003 05:46: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 1912Cq-0008A0-00 for emacs-devel@gnu.org; Thu, 03 Apr 2003 05:44:28 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.10) id 190eOs-0001w4-00; Wed, 02 Apr 2003 04:19:18 -0500 Original-To: Owen Taylor In-reply-to: <1049218005.16657.62.camel@localhost.localdomain> (message from Owen Taylor on 01 Apr 2003 12:26:45 -0500) Original-cc: jan.h.d@swipnet.se Original-cc: kai.grossjohann@uni-duisburg.de 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:12865 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12865 Your model is not simple either - you are just making it sound simple by neglecting the fact that there is some minimum size that you can make the scrollbar thumb. The thumb size is quantized because the display is made of pixels. Whatever model we use for the scroll bar will be distorted a little by quantization. This doesn't really affect any of the arguments. In fact, your doesn't work at all unless there is a difference between: - The minimum size the scrollbar thumb can under normal circumstances This minimum is irrelevant except for very large files. For instance, etc/NEWS is almost half a meg, and yet its thumb is several pixels high. A file would have to be several meg before its thumb would have the minimum possible height. However, quantization does cause problems. You cannot use mouse-2 to scroll were you will. In fact, a single pixel motion of the thumb in etc/NEWS corresponds to more than one screenful. If you scroll through the file using mouse-2, there are parts you will not even see. That is true regardless of how the scroll bar handles overscrolling. However, it does have a relationship with the issue of overscrolling. I compiled with some sort of athena widgets, and the behavior I get for overscrolling is the one that you want. If I slide the thumb all the way to the bottom, my screen is blank. But if I carefully position the thumb one pixel up from the bottom, the last line is off the bottom of the screen. There is no place to put the thumb which makes the end of the text visible. With the behavior I am recommending, sliding the thumb to the bottom would reliably make the last screenful of text visible. Many messages ago, you said: My suggestion is to display a thumb that rises from the bottom of the scroll bar, but is shorter than normal, as if the bottom of the thumb were hidden beyond the end of the scroll bar. Others may think of a better way to indicate this situation. I took that to understand that you wanted the bevelling drawn as if the scrollbar thumb was actually extending past the bottom of the scrollbar trough. Actually I wasn't thinking about that question. I don't know what GTK scrollbars look like, so I did not know they have beveling. Now that you mention it, I think it would be desirable to omit the bottom beveling, to indicate that the thumb virtually extends beyond the end of the trough. However, I am not saying that it should actually draw the thumb in the space beyond the end of the trough. I am saying that if it happens to do that, it is ok. For GTK+, I really want to preserve the idea that the scrollbar consists of a thumb of some length that can be positioned between two extremes - at the top of the trough and at the bottom of the trough. For it to change length while dragging is a bit peculiar. For it to go past the ends of the trough, either literally or by shrinking as it is pushed against the end is completely outside that model. When an application's internal concepts don't fit that model, trying to force it to fit does not help.