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: Fri, 29 Oct 2004 17:17:31 -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> <24DBCE88-298E-11D9-8B5E-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 1099084716 1165 80.91.229.6 (29 Oct 2004 21:18:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 29 Oct 2004 21:18:36 +0000 (UTC) Cc: emacs devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 29 23:18:25 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 1CNe8f-0001FK-00 for ; Fri, 29 Oct 2004 23:18:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CNeGW-0006H5-R7 for ged-emacs-devel@m.gmane.org; Fri, 29 Oct 2004 17:26:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CNeG0-00067B-Bu for emacs-devel@gnu.org; Fri, 29 Oct 2004 17:26:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CNeFz-00066c-A9 for emacs-devel@gnu.org; Fri, 29 Oct 2004 17:25:59 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CNeFz-00066S-6V for emacs-devel@gnu.org; Fri, 29 Oct 2004 17:25:59 -0400 Original-Received: from [206.47.199.165] (helo=simmts7-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CNe7p-0000cI-4x for emacs-devel@gnu.org; Fri, 29 Oct 2004 17:17:33 -0400 Original-Received: from empanada.home ([67.71.25.5]) by simmts7-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20041029211732.TGJY1960.simmts7-srv.bellnexxia.net@empanada.home>; Fri, 29 Oct 2004 17:17:32 -0400 Original-Received: by empanada.home (Postfix, from userid 502) id 0199C3435D2; Fri, 29 Oct 2004 17:17:31 -0400 (EDT) Original-To: "Jan D." In-Reply-To: <24DBCE88-298E-11D9-8B5E-000D93505B76@swipnet.se> (Jan D.'s message of "Fri, 29 Oct 2004 11:37:26 +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:29151 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29151 >>> 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? > No, but the 9 pages will be scrolled in 20 pixels. So no precision > scrolling is possible if you have many pages and a small window. It is the > same for any scroll bar, the minimum size is at least 1 pixel. And if you > have a window that is 40 pixels and the buffer is 1000 pages, you have to > scroll through 999 pages in 39 pixels. Basically the scroll bar is useless > in this situation. Yup. So you agree it's actually not specific to the fact that some themes have a minimum size for the thumb. The problem is simply that Gtk makes overscrolling "impossible", just like Xaw3d and Motif (used to) do. >>> 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. > I described previously in > http://lists.gnu.org/archive/html/emacs-devel/2004-10/msg01300.html Oh, I see. That's more or less what Xaw3d used to use. The problem with it was that the thumb was shrunk too late: - the user moves the mouse past the bottom. - the thumb is moved by Xaw3d to the bottom (and no further). - the callback is called and Emacs finally gets a chance to change the thumb size (but it doesn't know how far the mouse has moved: it only knows that it's at least gotton to the bottom, so it doesn't know how much to shrink it). - unless the user moves the mouse again, the position of the thumb is not updated to take into account the original "past the bottom" mouse movement. So what often happened is that you'd move the mouse past the bottom and then you'd have to wiggle it to get the callback to shrink the thumb little by little. Your suggestion to shrink it to 0 as soon as you hit the bottom would indeed help: you'd only have to move the mouse once after hitting bottom. In the case of Xaw3d an additional problem is that the Xaw3d code ignore(d|s) requests to change the size of the thumb while dragging (the xterm.c code has/had some really ugly hacks that accessed internal variables of Xaw3d to try and fool it into thinking it's not dragging). >>> 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. > If I change the maximum value, the thumb size changes. I then also have to > adjust the value otherwise the thumb changes position. Also, page_size > page_increment and step_increment has to be changed. Obviously this > is no more than to find a suitable algorithm, but the bad thing is that > the thumb almost always jump a bit when these values are changed. I'd think this algorithm is already written (to update the size and position of the thumb after point movement or buffer modifications). But as I said, I don't actually know what I'm talking about, so please ignore me here. > I used Xaw3d. The point that bothered me is if I have to pages in > a buffer, scrolling three lines involves a small mouse movement. > If I have three lines in the buffer, scrolling three lines involves a very > big mouse movement, even if I start with the mouse pointer in the same > place in both cases. If that's the only thing that bothered you with my Xaw3d code, I'm flattered ;-). After all, it's the desired behavior (and AFAICT this part of the behavior is common to all scrollbar implementations, even for other programs). Stefan