From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Scrollbar bug on OS X Date: Thu, 07 Apr 2005 00:25:10 +0200 Message-ID: References: <7ca1709813602da58a139cee58fb4c63@gmail.com> <3b9c4e2f33d37fed55f640dcafbc8d65@gmail.com> <87is31i8jq.fsf-monnier+emacs@gnu.org> <0ba853825b580f74347416c2c0b4a169@gmail.com> <87vf70ausz.fsf-monnier+emacs@gnu.org> <5b72982df8c370d3a58358de397046c8@gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1112826394 28802 80.91.229.2 (6 Apr 2005 22:26:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Apr 2005 22:26:34 +0000 (UTC) Cc: David Reitter , emacs-devel@gnu.org, Stefan Monnier , miles@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 07 00:26:32 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DJIxa-0001q6-7d for ged-emacs-devel@m.gmane.org; Thu, 07 Apr 2005 00:25:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DJIWk-00006i-VN for ged-emacs-devel@m.gmane.org; Wed, 06 Apr 2005 17:57:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DJIW2-0008Tl-Ns for emacs-devel@gnu.org; Wed, 06 Apr 2005 17:56:51 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DJIW1-0008SN-De for emacs-devel@gnu.org; Wed, 06 Apr 2005 17:56:49 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DJIxz-0004jp-4X for emacs-devel@gnu.org; Wed, 06 Apr 2005 18:25:43 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1DJIxE-0004ty-Up; Wed, 06 Apr 2005 18:24:57 -0400 Original-To: snogglethorpe@gmail.com In-Reply-To: (Miles Bader's message of "Thu, 7 Apr 2005 07:07:07 +0900") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:35656 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:35656 Miles Bader writes: > On Apr 6, 2005 11:32 PM, David Reitter wrote: >> that I'd like to implement in order to conform to standards in my >> environment, the vertical slider size shows a proportion of _ displayed >> lines_ not document characters or real lines (those that end with a CR >> or LF). Whether that is better or not, I don't know, but what I do know >> is that a) "less visual change on the screen is more", and that b) both >> Windows and Mac software has sliders with a stable size. > > The only way I can see to truly have stable scroll-bar size is to > base the size calculation on displayed pixels (lines are not > necessarily a constant height, so the number of displayed lines is > not a fixed proportion of total lines in the document). I think you are laboring under the delusion that the scroll bar actually displays something sensible, namely that mouse-2 exactly at the bottom of the slider will take you exactly one page of screen material further. I think you'll find that users are much less surprised if this goal is not exactly established than if the slider grows and shrinks in size. So the solution is to base the slider size on some more-or-less sensible metric like lines-in-file (where available) to lines-on-screen, and anyway, don't muck with it while dragging. > I'm curious how _any_ program manages to do this calculation in a > reasonable amount of time; do they really lay-out the _entire_ > document ahead of time? Do they use some sort of heuristic instead? > What happens when the heuristic fails? What should happen? The user will correct over/undershoot, probably not even considering that the computer could be at fault. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum