emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scrollbar bug on OS X


From: David Reitter
Subject: Re: Scrollbar bug on OS X
Date: Fri, 8 Apr 2005 14:12:33 +0100

On 8 Apr 2005, at 13:42, Stefan Monnier wrote:

There's consistency and there's consistency. In my experience, what people care about is "in which direction and by how much does my thingy move when I click with button X on part Y of the scrollbar" and "does the slider's
position and size reflect the part and quantity of my thingy that is
currently displayed".  The size of the slider while dragging is often
something they barely notice since while dragging they're not looking at the
scrollbar but at the thingy instead.  [ replace "thingy" with "buffer",
"spreadsheet", "html page", ...]

Of course there are priorities, and absolutely, the size of the scrollbar is less important than good scrolling behavior when you click underneath it or when you drag it. _Exact_ size - as pointed out by others before - might be totally unimportant. As it stands now, the scrollbars are jerking around in size, however, and when you try to drag the scrollbar, the displayed portion of the buffer will jump somewhere unpredictable.

Anyways, can I as a user please get the freedom to configure whether I like over-scrolling or not? ( cf. http://lists.gnu.org/archive/html/emacs-devel/2003-03/msg00593.html )

The only reason why you disagree is because you haven't tried to write the
code that interfaces something like Emacs with one of those silly
scrollbars.  After working on such code you realize that GUI guidelines
might be great, but they shouldn't be "cast in code" directly in the GUI
library because there are always exceptions.

What would be a good argument for such an exception?

The fact that it's hard to interface with the event-driven (or whatever) interface models of certain current APIs might be due to other players in this game than the UI toolkit.

Let's say one can state what would be good from a UI perspective, and then one will have to figure out what is reasonably doable from a technical standpoint. Arguments IMHO start with the user-centric view!

Either way, I would humbly suggest that the bugs be fixed first; I know it's hard and I know that I can't do it lacking knowledge of the technical implementation. And I understand these things are difficult, so I won't even try.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]