From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Addition to emacsbug.el Date: Wed, 27 Oct 2004 16:50:07 -0400 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <417F6C5E.5070801@swipnet.se> <417FF8DD.1000408@swipnet.se> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1098910251 22142 80.91.229.6 (27 Oct 2004 20:50:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 27 Oct 2004 20:50:51 +0000 (UTC) Cc: emacs devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 27 22:50:38 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 1CMuke-0008DN-00 for ; Wed, 27 Oct 2004 22:50:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CMusQ-0003oR-D2 for ged-emacs-devel@m.gmane.org; Wed, 27 Oct 2004 16:58:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CMusC-0003mF-Ud for emacs-devel@gnu.org; Wed, 27 Oct 2004 16:58:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CMusB-0003li-RN for emacs-devel@gnu.org; Wed, 27 Oct 2004 16:58:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CMusB-0003lY-N2 for emacs-devel@gnu.org; Wed, 27 Oct 2004 16:58:23 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CMukK-0006oN-NK for emacs-devel@gnu.org; Wed, 27 Oct 2004 16:50:16 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 748FD8282DB; Wed, 27 Oct 2004 16:50:16 -0400 (EDT) Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 3BA9D4AC80D; Wed, 27 Oct 2004 16:50:12 -0400 (EDT) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id 0AB078CA23; Wed, 27 Oct 2004 16:50:11 -0400 (EDT) Original-To: "Jan D." In-Reply-To: <417FF8DD.1000408@swipnet.se> (Jan D.'s message of "Wed, 27 Oct 2004 21:37:01 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 5) X-MailScanner-From: monnier@iro.umontreal.ca 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:29079 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29079 > 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. 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. > 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. I don't understand what you mean by "it doesn't work". In the above case, the thumb would start covering the whole scrollbar, but as soon as the drag starts you make it size 0, so the user can drag at will and the thumb will only hit the bottom of the scrollbar when the beginning of the thumb is at the bottom (i.e. when the last char of the buffer is at the top of the window). The problem of not being able to move past the bottom is just the same in Xaw3d. Well, was, since AFAIK Xaw3g version 1.5g fixes it (it can be argued that it was a bug since it didn't follow the Xaw behavior). > 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. Isn't that a small matter of programming (I mean, Emacs does change the size of the thumb, already, right?). > 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. Yes, that's exactly what I mean by "perfect behavior", except that your description only focuses on the scrollbar, whereas one key aspect is how it relates to the actual buffer text displayed: when the thumb hits the bottom is when the EOB is displayed. > 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. Currently a fair bit of code is shared, but not all of it. the current imperfect solution uses different tricks for different toolkits. My suggested new imperfect solution is less dependent on details of the toolkits so it reduces the among of toolkit-specific tweaks. Check the patch I sent. BTW, what about the other part of my patch: merge xg_set_toolkit_scroll_bar_thumb back into x_set_toolkit_scroll_bar_thumb ? Stefan