From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Newsgroups: gmane.emacs.devel Subject: Re: Addition to emacsbug.el Date: Thu, 28 Oct 2004 15:54:40 -0400 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <417F6C5E.5070801@swipnet.se> <417FF8DD.1000408@swipnet.se> <9B209D7F-28A9-11D9-AAAE-000D93505B76@swipnet.se> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1098993362 6205 80.91.229.6 (28 Oct 2004 19:56:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 28 Oct 2004 19:56:02 +0000 (UTC) Cc: emacs devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 28 21:55:46 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CNGN7-0003IK-00 for ; Thu, 28 Oct 2004 21:55:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CNGUv-0006NO-Pq for ged-emacs-devel@m.gmane.org; Thu, 28 Oct 2004 16:03:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CNGUi-0006Kz-TZ for emacs-devel@gnu.org; Thu, 28 Oct 2004 16:03:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CNGUi-0006KX-5q for emacs-devel@gnu.org; Thu, 28 Oct 2004 16:03:36 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CNGUh-0006KH-Ty for emacs-devel@gnu.org; Thu, 28 Oct 2004 16:03:35 -0400 Original-Received: from [206.47.199.165] (helo=simmts7-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CNGM5-0004sV-Pq for emacs-devel@gnu.org; Thu, 28 Oct 2004 15:54:42 -0400 Original-Received: from empanada.home ([67.71.35.140]) by simmts7-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20041028195440.FYBW1960.simmts7-srv.bellnexxia.net@empanada.home>; Thu, 28 Oct 2004 15:54:40 -0400 Original-Received: by empanada.home (Postfix, from userid 502) id EC12D33FC11; Thu, 28 Oct 2004 15:54:40 -0400 (EDT) Original-To: "Jan D." In-Reply-To: <9B209D7F-28A9-11D9-AAAE-000D93505B76@swipnet.se> (Jan D.'s message of "Thu, 28 Oct 2004 08:21:30 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (darwin) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:29120 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29120 >> Well, it's a question of taste, obviously. I myself introduced the idea >> of "empty virtual page" in the Xaw3d code (so if you're looking at a 25 >> lines buffer in a 25-lines window, the thumb is only covering half of the >> scrollbar). But after using it for a while I decided I didn't like it >> because I was never sure whether there was still something left in the >> buffer (typically when reading Gnus messages). There are various ways to >> provide some other visual feedback, but experience showed that the >> scrollbar is the feedback that I use. > For GTK at least some compromise is needed. Some themes have a minimum > size for the thumb. So if the thumb is at its minimum size > the overscrolling with the thumb shrinking can't happen. Huh? Are you sure? I'd expect that the display-size of the thumb is "unrelated" to the size as specified by the C code. What if your document is made of 10 pages and your scrollbar is 40 pixels and your minimum thumb size is 20 pixels, is GTK going to prevent you from seeing more than 2 pages? > If the shown portion of the buffer is small compared to the total size of > the buffer, I think the virtual page behaviour is OK. After all, can you > see the difference between a thumb who has a height that is 1/30 of the > window height, or 1/31? Agreed: the exact size of the thumb doesn't matter that much. But I can usually still see whether the thumb is "at the bottom" or whether there's still one or 2 pixels left, so as long as 1 pixels represents about 20 lines the difference is "relevant" (i.e. 20 lines =~ 500 chars => a buffer of about 500B * 1000 pixels = 500KB for my typical frames). By "relevant" I don't mean important, but just that it's not 100% negligeable. I could probably happily live with the "virtual extra page" for buffers as small as 50KB. > Otherwise we should do something else, be it your solution or the thumb > shrinking one. I don't know what is the "thumb shrinking" solution. > To change the thumb size means fiddling with the page size and the maximum > values for the scroll bar. Relating values back to a buffer position then > becomes so much harder. Not impossible, but certainly a lot of testing > needs to be done. Hmm... I'll trust you on that one because I obviously don't understand the difficulty: the way the xterm.c code uses SB_MAX or equivalent as the "maximum value" it would work exactly the same whether SB_MAX is a constant or not. > There is another thing I noticed about your patch. If the buffer contains > three lines and the window is 34 lines, the thumb covers the whole window. > Now, if I start to scroll down putting the pointer somewhere at the top > of the thumb, I'll have to move down to half the window before one line > is actually scrolled. Then down to 3/4 before the second line is scrolled > and finally to the bottom to get the third line to scroll. > Now, if I start with the pointer near the bottom of the thumb, the two > first lines are scrolled just by moving the pointer one pixel. > I think the amount you move the pointer should determine how many lines > are scrolled, not where you happen to put the pointer when you start. > Also, the amount to move for scrolling one line should be the same > regardless of the size of the buffer or the amount show. Well, obviously this actually depends on the toolkit in use (in Xaw3d, the thumb is always moved to the mouse pointer during grab, so the position of the mouse pointer is what matters, rather than the distance you move it). What toolkit were you using in the above described case? My patch is only really tested with Xaw3d. > The code shared is smaller than the code that differs, so I really don't > see the point. But if the shared code could go into a function of its > own that would make sense. For GTK it was convinient to have all code > that modifies the scroll bars in one file when changes had to be done. Well, I was hoping the code that differs could be reduced further (I didn't have GTK installed when I did the merge, so I didn't get to check whether it compiled, and I haven't tried to change the code to adapt to the "squash thumb to 0-size during drag" to GTK: this change has reduced the code-difference between Xaw3d and Motif (and non-toolkit) to one or two lines only, so I'm hoping something similar can happen with GTK). Stefan