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: Thu, 28 Oct 2004 08:21:30 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <9B209D7F-28A9-11D9-AAAE-000D93505B76@swipnet.se> References: <417F6C5E.5070801@swipnet.se> <417FF8DD.1000408@swipnet.se> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1098944546 25903 80.91.229.6 (28 Oct 2004 06:22:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 28 Oct 2004 06:22:26 +0000 (UTC) Cc: emacs devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 28 08:22:17 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 1CN3ft-0003b2-00 for ; Thu, 28 Oct 2004 08:22:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CN3nf-0000nk-Pb for ged-emacs-devel@m.gmane.org; Thu, 28 Oct 2004 02:30:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CN3nX-0000nT-Gc for emacs-devel@gnu.org; Thu, 28 Oct 2004 02:30:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CN3nX-0000nF-03 for emacs-devel@gnu.org; Thu, 28 Oct 2004 02:30:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CN3nW-0000nC-TS for emacs-devel@gnu.org; Thu, 28 Oct 2004 02:30:10 -0400 Original-Received: from [195.54.107.70] (helo=mxfep01.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CN3fG-0001g7-Od for emacs-devel@gnu.org; Thu, 28 Oct 2004 02:21:39 -0400 Original-Received: from coolsville.localdomain ([83.226.180.220] [83.226.180.220]) by mxfep01.bredband.com with ESMTP id <20041028062137.JQXH4883.mxfep01.bredband.com@coolsville.localdomain>; Thu, 28 Oct 2004 08:21:37 +0200 In-Reply-To: Original-To: Stefan Monnier X-Mailer: Apple Mail (2.619) 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:29094 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29094 >> 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. 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. 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? Otherwise we should do something else, be it your solution or the thumb shrinking one. > >> 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). 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. > > 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?). Yes, in principle that is correct. > >> 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. 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. > >> 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 ? 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. Jan D.