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: Addition to emacsbug.el Date: Wed, 27 Oct 2004 21:37:01 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <417FF8DD.1000408@swipnet.se> References: <417F6C5E.5070801@swipnet.se> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1098906432 10492 80.91.229.6 (27 Oct 2004 19:47:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 27 Oct 2004 19:47:12 +0000 (UTC) Cc: emacs devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 27 21:46:54 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 1CMtkz-0001vr-00 for ; Wed, 27 Oct 2004 21:46:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CMtsk-0007Ma-SA for ged-emacs-devel@m.gmane.org; Wed, 27 Oct 2004 15:54:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CMtsd-0007ML-4K for emacs-devel@gnu.org; Wed, 27 Oct 2004 15:54:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CMtsc-0007Ly-Bh for emacs-devel@gnu.org; Wed, 27 Oct 2004 15:54:46 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CMtsb-0007Lv-Tv for emacs-devel@gnu.org; Wed, 27 Oct 2004 15:54:46 -0400 Original-Received: from [195.54.107.73] (helo=mxfep02.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CMtkc-00042k-IW for emacs-devel@gnu.org; Wed, 27 Oct 2004 15:46:31 -0400 Original-Received: from coolsville.localdomain ([83.226.180.220] [83.226.180.220]) by mxfep02.bredband.com with ESMTP id <20041027193737.FHVM44.mxfep02.bredband.com@coolsville.localdomain>; Wed, 27 Oct 2004 21:37:37 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040916 X-Accept-Language: en-us, en Original-To: Stefan Monnier In-Reply-To: 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:29076 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29076 Stefan Monnier wrote: >>I'm working on the GTK scroll bars again, trying to get overscrolling to >>work as in the native scroll bars. But I see that depending on what GTK >>version and what X server version I run on (specifically with DAMAGE >>extension or not), I sometimes get different behaviour. Therefore I would >>like to have this information inserted by report-emacs-bug. The GTK version >>is already in emacs-version, so I propose this patch to emacsbug.el: > > > BTW, with the Xaw3d scrollbars (which had/have the same problem), I've been > using the following trick very happily: > - use the "normal" thumb position and size (the same as was used for the > non-toolkit scroll bars). > - at the beginning of a thumb-drag, set the thumb size to 0. > - at the end of a thumb-drag reset the thumb-size to its real value. > > I find this to be the best solution to the problem: from the code's point of > view, it's clean and simple (much cleaner and simpler than the hacks that > are currently used in xterm.c). From the user's point of view, it makes > dragging a bit strange at first because the thumb almost disappears under > the mouse cursor, but to make up for it, the actual behavior during dragging > is now flawless and so is the rest of the behavior. Hmm, I don't like it. First of all, it is during a thumb-drag that you actually look at the thumb and the feedback you get from the size of the thumb (how much of the whole we are viewing, and where we currently are) is most useful. Also, the thumb does not always show up under the mouse pointer, but often quite a bit from it. If I continue to drag, the thumb jumps to the pointer. I'd rather keep the current GTK behaviour, with a thumb size that includes the empty virtual page, but others may feel different. Secondly it does not work at all for GTK. The event from the scroll bar stops when the thumb hits the bottom, so overscrolling for a window where the whole contents is shown does not happen. Also, GTK thumbs can not be resized with ease like the Xaw and Motif ones, it involves setting the page size and the max and min just right. > Since we can't have a perfect behavior I find this trade off to be much > better than anything I've seen so far. It depends on what we consider the perfect behaviour. My idea (and I thought the other versions of Emacs behaved like this already, I don't use scroll bars much) is that when the thumb hits the bottom we enter overscrolling mode. In that mode the thumb smoothly shrinks if dragged down further, and grows again if dragged up. Say you have a buffer with two pages, and if one page is visible the thumb is half the size of the window. You drag down the thumb to the bottom, so that the top of page two is at the top of the window. If you drag down further, the thumb shrinks until the bottom of page two is at the top of the window. The thumb in this case shrinks to a minimum of a third of the window height (2 real pages and one virtual). I am not sure if there is a general way to do this (resizing of thumbs and event handling differ between toolkits), or if it must be done individually for each toolkit. Perhaps if this is done for two toolkits we can then rewrite it in a general way. That would be 22.0 stuff I think. But as GTK is just one toolkit and the scroll code to modify is either all in gtkutils.c or #ifdef:ed USE_GTK in xterm, the risc is low. I have a test program that does just this for GTK, but it is one thing to write a pure GTK program and another to get the same behaviour in Emacs. I hope it can be done. Also, I haven't tested with complicated themes yet. Jan D.