From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Owen Taylor Newsgroups: gmane.emacs.devel Subject: Re: Gtk scrollbar: thumb too short Date: 01 Apr 2003 12:26:45 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <1049218005.16657.62.camel@localhost.localdomain> References: <20030325193739.ZGIN3924.fep01-svc.swip.net@gaffa.gaia.swipnet.se> <3E8345E8.4090509@swipnet.se> <1048872463.17161.132.camel@localhost.localdomain> <1049134327.3326.74.camel@localhost.localdomain> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1049219722 30941 80.91.224.249 (1 Apr 2003 17:55:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 1 Apr 2003 17:55:22 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Apr 01 19:55:16 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 190PtE-0007dn-00 for ; Tue, 01 Apr 2003 19:49:40 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 190Ptv-0004Q4-00 for ; Tue, 01 Apr 2003 19:50:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 190PrO-00024a-03 for emacs-devel@quimby.gnus.org; Tue, 01 Apr 2003 12:47:46 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 190PlR-0005xK-00 for emacs-devel@gnu.org; Tue, 01 Apr 2003 12:41:37 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 190PhD-0002yX-00 for emacs-devel@gnu.org; Tue, 01 Apr 2003 12:37:17 -0500 Original-Received: from nat-pool-rdu.redhat.com ([66.187.233.200] helo=lacrosse.corp.redhat.com) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 190PYo-0007Se-00; Tue, 01 Apr 2003 12:28:35 -0500 Original-Received: from landau.devel.redhat.com (landau.devel.redhat.com [172.16.56.103])h31HSVu28810; Tue, 1 Apr 2003 12:28:31 -0500 Original-To: rms@gnu.org In-Reply-To: X-Mailer: Ximian Evolution 1.2.2 (1.2.2-0) Original-cc: jan.h.d@swipnet.se Original-cc: kai.grossjohann@uni-duisburg.de X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:12805 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12805 On Tue, 2003-04-01 at 04:38, Richard Stallman wrote: > > That is unnecessarily complicated. I think the position value that > > users see is thumb_start / trough_pixels. That is much simpler > > and it is visually evident. > > For the normal case, these two approaches are the same. > > The two models are mathematically equivalent in the normal case, but I > conjecture that the simple one is the way users really understand it. > In unusual cases, where the two models disagree, preserving the simple > model will seem natural. Preserving the complex model will seem > unnatural. Your model is not simple either - you are just making it sound simple by neglecting the fact that there is some minimum size that you can make the scrollbar thumb. When the scrollbar is at that minimum size, that must correspond to the bottom scroll position. So, there is a scale factor in your approach too. > But in more complicated cases, your approach isn't possible. > > Of course it is possible. Emacs already does it, with some toolkits. See above. Unless you allow the scrollbar to go down to 1 pixel or less, which I don't think you do, there is non-simple scaling involved. In fact, your doesn't work at all unless there is a difference between: - The minimum size the scrollbar thumb can under normal circumstances - The minimum size the scrollbar thumb can be be at the end of the trough. Because it's the difference between those two sizes that ends up representing the overscrolling for a sufficiently large buffer. But GTK+ doesn't have two minimum sizes, it just has one minimum size ... the minimum size that a theme can draw the scrollbar thumb. So, even if we modified GTK+ to allow dragging past the end position, for more than medium-sized buffers, you'd still have to figure out how to deal with the case where the scrollbar thumb couldn't get smaller at the end of the document. > You get a situation where the correct size of the thumb cannot > fit into the trough with that starting position, which gives > you two choices: > > - Make the thumb go out of the trough. > > I think there is a misnunderstanding here. Nobody proposed this. You > said that some themes might do this, as a consequence of how the code > works; I responded it is no problem if they do. Many messages ago, you said: My suggestion is to display a thumb that rises from the bottom of the scroll bar, but is shorter than normal, as if the bottom of the thumb were hidden beyond the end of the scroll bar. Others may think of a better way to indicate this situation. I took that to understand that you wanted the bevelling drawn as if the scrollbar thumb was actually extending past the bottom of the scrollbar trough. > - Shrink the thumb to a smaller size than it should be. > While less of a problem than the previous approach, > it strikes me as a little strange. Also, you still have > to consider what happens when you reach some minimum > size for the handlebar. > > This is what should happen. This is what Emacs already does > on some platforms. (What is the "handlebar"?) "Thumb", sorry. > I'm not sure that presenting this simple model to the user > is compatible with allowing the user to drag the scrollbar thumb > to overscroll. > > They must be compatible; they already work together on other > platforms. It is somewhat hard to grab the thumb when most of the > thumb is off-screen, but it should not be impossible. > > You have to decide whether dragging the scrollbar to the bottom: > > - Scrolls to last page of the document > > Dragging it to the bottom of the trough should scroll to the last full > page. Dragging it beyond the bottom should show less than a full > page. > > (Note that by allowing the user to drag the thumb to overscroll, > no matter how you do it, you make the operation of scrolling > to the last page of the document a precision operation rather > > That is true, but the amount of precision required is no more than for > scrolling at any other place in the document. Emacs has worked this > way for many years, and we have not heard a complaint. I think scrolling to the end of the document is a more interesting operation than scrolling to some other place in the document. Actually, it would be interesting to know what percentage of emacs users actually _drag_ the scrollbar to navigate in a document; it's quite possible the primary use of the scrollbar is as a visual indicator of where the current viewport is located within the document. In which case, it's not clear to me that the scrollbar is the right control at all. For GTK+, I really want to preserve the idea that the scrollbar consists of a thumb of some length that can be positioned between two extremes - at the top of the trough and at the bottom of the trough. For it to change length while dragging is a bit peculiar. For it to go past the ends of the trough, either literally or by shrinking as it is pushed against the end is completely outside that model. Regards, Owen