From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Owen Taylor Newsgroups: gmane.emacs.devel Subject: Re: Gtk scrollbar: thumb too short Date: 31 Mar 2003 13:12:07 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <1049134327.3326.74.camel@localhost.localdomain> References: <20030325193739.ZGIN3924.fep01-svc.swip.net@gaffa.gaia.swipnet.se> <3E8345E8.4090509@swipnet.se> <1048872463.17161.132.camel@localhost.localdomain> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1049134993 10385 80.91.224.249 (31 Mar 2003 18:23:13 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 31 Mar 2003 18:23:13 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Mar 31 20:23:07 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 1903w3-0002gk-00 for ; Mon, 31 Mar 2003 20:23:07 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 1903wG-0007VR-00 for ; Mon, 31 Mar 2003 20:23:20 +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 1903vg-0004Ws-01 for emacs-devel@quimby.gnus.org; Mon, 31 Mar 2003 13:22:44 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 1903vK-0004Uy-00 for emacs-devel@gnu.org; Mon, 31 Mar 2003 13:22:22 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 1903vI-0004U3-00 for emacs-devel@gnu.org; Mon, 31 Mar 2003 13:22:21 -0500 Original-Received: from nat-pool-rdu.redhat.com ([66.187.233.200] helo=lacrosse.corp.redhat.com) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 1903nA-00017c-00; Mon, 31 Mar 2003 13:13:56 -0500 Original-Received: from landau.devel.redhat.com (landau.devel.redhat.com [172.16.56.103])h2VIDoo08683; Mon, 31 Mar 2003 13:13:50 -0500 Original-To: rms@gnu.org In-Reply-To: X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) 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:12770 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12770 On Sun, 2003-03-30 at 14:24, Richard Stallman wrote: > An observation I'd make is that a scrollbar really encodes two > things: > > - A value > - A percentage of a total size > > If we look at the scrollbar on the screen, we have: > > v = thumb_start / (trough_pixels - thumb_pixels) > p = thumb_pixels / trough_pixels > > That is unnecessarily complicated. I think the position value that > users see is thumb_start / trough_pixels. That is much simpler > and it is visually evident. For the normal case, these two approaches are the same. But in more complicated cases, your approach isn't possible. The normal situation where this comes up in GTK+ is when the thumb is clamped to its minimum size. > For the normal GTK+ case these two quantities are related to the > document size. > > v = start_of_visible / MAX (size_of_visible, size_of_document) - size_of_visible > > thumb_start / trough_pixels normally corresponds to > start_of_visible / MAX (size_of_visible, size_of_document) > > If this relationship continues to apply when Emacs overscrolls, > you get the behavior I have asked for. You get a situation where the correct size of the thumb cannot fit into the trough with that starting position, which gives you two choices: - Make the thumb go out of the trough. As discussed earlier, this will cause drawing problems, and also may cause problems for the ability of the user to click and drag on the thumb. The scrollbar models a physical system where there is a knob slid along a trough. If in the physical system (a stereo component say), the knob popped out of the trough on the physical system, it would be a sign of shoddy workmanship. I think the same holds for the onscreen case. - Shrink the thumb to a smaller size than it should be. While less of a problem than the previous approach, it strikes me as a little strange. Also, you still have to consider what happens when you reach some minimum size for the handlebar. > I think of the scroll bar as showing how the document is divided into > three parts: the part above the screen, the part on the screen, and > the part below the screen. The sizes of the three parts of the scroll > bar are in proportion to those three parts of the document. > > When Emacs overscrolls, the last part of the document has negative > size. Properly speaking, the thumb should extend beyond the end of > the trough. Alas, that is impossible. The Emacs 20.7 behavior is the > closest possible approximation. I'm not sure that presenting this simple model to the user is compatible with allowing the user to drag the scrollbar thumb to overscroll. While you may think of the scrollbar as a miniature view of the document, it is also presented to the user as a physical control, with obvious limits as to how far the scrollbar can be dragged. You have to decide whether dragging the scrollbar to the bottom: - Scrolls to last page of the document - Scrolls to the maximally overscrolled position (one line at the top of the screeen) (Note that by allowing the user to drag the thumb to overscroll, no matter how you do it, you make the operation of scrolling to the last page of the document a precision operation rather than something where the user can just drag the scrollbar down as far as it can go quickly.) Regards, Owen