From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: Gtk scrollbar: thumb too short Date: Fri, 28 Mar 2003 19:25:08 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <9ABFBA7E-614A-11D7-AF93-00039363E640@swipnet.se> References: <1048866256.17532.39.camel@localhost.localdomain> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1048876192 994 80.91.224.249 (28 Mar 2003 18:29:52 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 28 Mar 2003 18:29:52 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Mar 28 19:29:48 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 18yybs-0000Fl-00 for ; Fri, 28 Mar 2003 19:29:48 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18yyeM-0007H9-00 for ; Fri, 28 Mar 2003 19:32:22 +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 18yyZj-0001YQ-03 for emacs-devel@quimby.gnus.org; Fri, 28 Mar 2003 13:27:35 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18yyYT-0008Oq-00 for emacs-devel@gnu.org; Fri, 28 Mar 2003 13:26:17 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18yyYO-0008CV-00 for emacs-devel@gnu.org; Fri, 28 Mar 2003 13:26:13 -0500 Original-Received: from stubby.bodenonline.com ([193.201.16.94]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18yyXx-0007Si-00; Fri, 28 Mar 2003 13:25:46 -0500 Original-Received: from accessno42.bodenonline.com (IDENT:root@accessno42.bodenonline.com [193.201.16.44]) h2SJHcbL016113; Fri, 28 Mar 2003 20:17:43 +0100 Original-To: Owen Taylor In-Reply-To: <1048866256.17532.39.camel@localhost.localdomain> X-Mailer: Apple Mail (2.551) Original-cc: rms@gnu.org Original-cc: kai.grossjohann@uni-duisburg.de Original-cc: jody@gnome.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:12717 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12717 > I think there is a strong case to be made that the length of the > scrollbar trough is > > MAX (length of document, maximum visible position) > > rather than simple the length of the document. Consider the case > where the document is shorter than the screen height. In that case, > there is a strong expectation that the thumb extends the entire > length of the trough, and Emacs does that currently. Actually it doesn't for GTK and Motif scroll bars. If there are three lines in a buffer and the window can display 25, space is made at the bottom so that one can scroll those three lines. We tell the scroll bar that the maximum size is 28 lines and the page size is 25 (more or less). > If you _didn't_ do that, then you'd have a scrollbar that only > occupies part of the trough but that it was impossible to drag > up and down. While that might make logical sense, it would be > highly confusing. If it could not be manipulated that would be bad. > So if this interpretation of the trough length corresponding > to: > > MAX (length of document, maximum visible position) > > is used for documents shorter than the screen, I don't see a > reason why it can't be used for the case of overscrolling as > well. The main difficulty would be when to take the overscrolled > area out of the trough size computation... usually you > want to do it immediately, but when the user is dragging the > scrollbar, probably not until they release the mouse. > > To do that with GTK+ currently, is a bit of a hack, you > have to connect to the ::button-release-event signal on the > scrollbar. But I think it would be a reasonable RFE for GTK+ > to have some clean way of finding out when the drag finishes. If GTK had some way to indicate that the user pressed on the arrow it would be easy to take that into account also. Jan D.