Re: vertical scrollbar error on MS Windows

Re: vertical scrollbar error on MS Windows

[Kim F. Storm]

>
>> As far as I remember scrolling was always problematic (in the same
>> way?) in W32 Emacses, so this is not a new bug?

I just installed some changes to _improve_ on those scroll-bar issues.

Can you -- and other W32 users -- please try out the latest CVS
and tell me ASAP if there are still _severe_ problems with it.

At least it seems to work a lot better than before, but we need
as much testing as possible BEFORE to the release (which *is*
very close now!!).

So, also tell me if you tested it, and didn't find any problems!

Thanks.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: vertical scrollbar error on MS Windows

[Juanma Barranquero]

On 2/19/07, Kim F. Storm <storm@cua.dk> wrote:

> Can you -- and other W32 users -- please try out the latest CVS
> and tell me ASAP if there are still _severe_ problems with it.

Hard to say what is a severe problem. With the sample file (scroll.txt):

 - Make the frame's height 30 lines.
 - Visit scroll.txt
 - Move point to eob.
 - Scroll up to bob.
 - Release the mouse button.
 - Scroll down.

I can't get past line 46.

             Juanma

Re: vertical scrollbar error on MS Windows

[Lennart Borgman (gmail)]

Kim F. Storm wrote:
>>> As far as I remember scrolling was always problematic (in the same
>>> way?) in W32 Emacses, so this is not a new bug?
> 
> I just installed some changes to _improve_ on those scroll-bar issues.
> 
> Can you -- and other W32 users -- please try out the latest CVS
> and tell me ASAP if there are still _severe_ problems with it.
> 
> At least it seems to work a lot better than before, but we need
> as much testing as possible BEFORE to the release (which *is*
> very close now!!).
> 
> So, also tell me if you tested it, and didn't find any problems!
> 
> Thanks.


I have uploaded a new unpatched version Emacs+EmacsW32 for those who 
want to test:

  http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl

Re: vertical scrollbar error on MS Windows

[Kim F. Storm]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 2/19/07, Kim F. Storm <storm@cua.dk> wrote:
>
>> Can you -- and other W32 users -- please try out the latest CVS
>> and tell me ASAP if there are still _severe_ problems with it.
>
> Hard to say what is a severe problem. With the sample file (scroll.txt):
>
> - Make the frame's height 30 lines.
> - Visit scroll.txt
> - Move point to eob.
> - Scroll up to bob.
> - Release the mouse button.
> - Scroll down.
>
> I can't get past line 46.

That's right, but still it is not worse than before.

I don't see an easy fix for this, so let's leave it for
after the release.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: vertical scrollbar error on MS Windows

[Peter Tury]

Hi,

thanks for the quick fix!

I tried latest Emacs W32 (U070219) and for me it seems to be OK: I
haven't found any problems with vscrolling.

Br,
P

2007/2/19, Lennart Borgman (gmail) <lennart.borgman@gmail.com>:
> Kim F. Storm wrote:
> >
> > Can you -- and other W32 users -- please try out the latest CVS
> > and tell me ASAP if there are still _severe_ problems with it.
> >
> > At least it seems to work a lot better than before, but we need
> > as much testing as possible BEFORE to the release (which *is*
> > very close now!!).
> >
> > So, also tell me if you tested it, and didn't find any problems!
> >
> I have uploaded a new unpatched version Emacs+EmacsW32 for those who
> want to test

Re: vertical scrollbar error on MS Windows

[Juanma Barranquero]

On 2/19/07, Kim F. Storm <storm@cua.dk> wrote:

> That's right, but still it is not worse than before.

Aha. I didn't know, I always work without scroll bars.

> I don't see an easy fix for this, so let's leave it for
> after the release.

Agreed.

             Juanma

Re: vertical scrollbar error on MS Windows

[Nick Roberts]

 > > That's right, but still it is not worse than before.
 > 
 > Aha. I didn't know, I always work without scroll bars.
 > 
 > > I don't see an easy fix for this, so let's leave it for
 > > after the release.
 > 
 > Agreed.

Yes, the notion that you can't scroll without a scrollbar is nonsense.  I
use the following in my .emacs:

  (defun scroll-up-one-line ()
  "Move down one line at a time."
  (interactive)
  (scroll-up 1))

  (defun scroll-down-one-line ()
  "Move up one line at a time."
  (interactive)
  (scroll-down 1))

  (define-key global-map  [f5] 'scroll-up-one-line)
  (define-key global-map  [f6] 'scroll-down-one-line)

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: vertical scrollbar error on MS Windows

[grischka]

[-- Attachment #1: Type: text/plain, Size: 239 bytes --]

Hi there,

Here is another fix for the scrollbars. From the approach
it calculates the thumb length once on mouse down and 
then leaves bar parameters alone during dragging. Patch 
for w32term.c is in the attachement.

Regards
-- grischka

[-- Attachment #2: w32term.c.diff --]
[-- Type: application/octet-stream, Size: 3482 bytes --]

--- c:/checkout/emacs-cvs/emacs/src/w32term.c	Tue Feb 20 02:22:42 2007
+++ w32term.c	Wed Feb 21 00:10:48 2007
@@ -3468,11 +3468,70 @@
 /* Set the thumb size and position of scroll bar BAR.  We are currently
    displaying PORTION out of a whole WHOLE, and our position POSITION.  */
 
+#define SCROLL_FIX
+
 static void
 w32_set_scroll_bar_thumb (bar, portion, position, whole)
      struct scroll_bar *bar;
      int portion, position, whole;
 {
+#ifdef SCROLL_FIX
+    Window w;
+    BOOL draggingp = !NILP (bar->dragging) ? TRUE : FALSE;
+    SCROLLINFO si;
+    int sb_page, sb_pos, range, window, lines, n, mem;
+
+    static int was_draggingp;
+    if (draggingp && was_draggingp)
+        return;
+    was_draggingp = draggingp;
+
+    // scan some text
+    mem = whole;
+    if (mem > 20000)
+        mem = 20000;
+
+    for (lines = 0, n = 1; n <= mem; ++n)
+        if (FETCH_BYTE(n) == '\n')
+            ++lines;
+
+    window = WINDOW_TOTAL_LINES (XWINDOW (bar->window));
+    range = VERTICAL_SCROLL_BAR_INSIDE_HEIGHT (f, XINT(bar->height));
+
+    if (mem == whole) {
+        sb_page = range * window / (lines + window);
+    } else {
+        window = window * mem / (lines + 1); // in bytes, avg.
+        sb_page = range * window / (whole + window);
+    }
+
+    // bigger is nicer for them with a cheap mouse
+    n = VERTICAL_SCROLL_BAR_INSIDE_WIDTH (f, XINT(bar->width));
+    if (sb_page < n) {
+        sb_page = n;
+        // but not too big ...
+        n = range/4;
+        if (sb_page > n)
+            sb_page = n;
+    }
+
+    if (0 == whole)
+        sb_pos = 0;
+    else
+        sb_pos = ((double) position * (range - sb_page) + whole - 1) / whole;
+
+    si.cbSize = sizeof (si);
+    si.fMask = SIF_PAGE | SIF_POS | SIF_RANGE | SIF_DISABLENOSCROLL;
+    si.nMin = 0;
+    si.nMax = range - 1;
+    si.nPage = sb_page;
+    si.nPos = sb_pos;
+
+    w = SCROLL_BAR_W32_WINDOW (bar);
+    SetScrollInfo (w, SB_CTL, &si, TRUE);
+    return;
+
+#else
   Window w = SCROLL_BAR_W32_WINDOW (bar);
   /* We use the whole scroll-bar height in the calculations below, to
      avoid strange effects like scrolling backwards when just clicking
@@ -3538,6 +3597,7 @@
   SetScrollInfo (w, SB_CTL, &si, TRUE);
 
   UNBLOCK_INPUT;
+#endif
 }
 
 \f
@@ -3946,9 +4006,15 @@
     si.cbSize = sizeof (si);
     si.fMask = SIF_POS;
 
+#ifdef SCROLL_FIX
+    si.fMask = SIF_POS|SIF_RANGE|SIF_PAGE; //gr
+#endif
     GetScrollInfo ((HWND) msg->msg.lParam, SB_CTL, &si);
     y = si.nPos;
 
+#ifdef SCROLL_FIX
+    top_range = si.nMax + 1 - si.nPage; //gr
+#endif
     bar->dragging = Qnil;
 
 
@@ -3983,6 +4049,7 @@
 	bar->dragging = Qt;
 	emacs_event->part = scroll_bar_handle;
 
+#ifndef SCROLL_FIX
 	/* "Silently" update current position.  */
 	{
 	  SCROLLINFO si;
@@ -3996,11 +4063,13 @@
 
 	  SetScrollInfo (SCROLL_BAR_W32_WINDOW (bar), SB_CTL, &si, FALSE);
 	}
+#endif
 	break;
       case SB_ENDSCROLL:
 	/* If this is the end of a drag sequence, then reset the scroll
 	   handle size to normal and do a final redraw.  Otherwise do
 	   nothing.  */
+#ifndef SCROLL_FIX
 	if (dragging)
 	  {
 	    SCROLLINFO si;
@@ -4013,6 +4082,7 @@
 	    si.nPos = last_scroll_bar_drag_pos;
 	    SetScrollInfo (SCROLL_BAR_W32_WINDOW (bar), SB_CTL, &si, TRUE);
 	  }
+#endif
 	/* fall through */
       default:
 	emacs_event->kind = NO_EVENT;

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: vertical scrollbar error on MS Windows

[Kim F. Storm]

"grischka" <grishka@gmx.de> writes:

> Hi there,
>
> Here is another fix for the scrollbars. From the approach
> it calculates the thumb length once on mouse down and 
> then leaves bar parameters alone during dragging. Patch 
> for w32term.c is in the attachement.

Thank you.

But I think this change is too radical at this time.

Counting lines like that does not always give a
correct answer - e.g. if there are overlays / images
in the buffer.

I think we need to rethink the whole scrolling functionality
after the release (also for the other ports).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: vertical scrollbar error on MS Windows

[grischka]

Kim F. Storm writes:

> "grischka" writes:
> 
> > Hi there,
> >
> > Here is another fix for the scrollbars. From the approach
> > it calculates the thumb length once on mouse down and 
> > then leaves bar parameters alone during dragging. Patch 
> > for w32term.c is in the attachement.
> 
> Thank you.
> 
> But I think this change is too radical at this time.
> 
> Counting lines like that does not always give a
> correct answer - e.g. if there are overlays / images
> in the buffer.
> 

Shure, but then it does not really matter whether the 
slider is a bit longer or shorter in cases.

It is important on the UI level however, that there is a 
reliable relation between slider position and text view, 
i.e. that the visual feedback is consistent with the hand's 
movement. Otherwise it feels like a loose handle bar on
a bicyle.

For example even with your patch there is still the problem 
that sometimes the slider shrinks in the end as supposed, 
while with other files it remains stuck and it's not possible 
to see the last line. Or sometimes the slider shrinks itself 
on mouse down already such that mouse points into void. Etc. 

> I think we need to rethink the whole scrolling functionality
> after the release (also for the other ports).

No objection to that. Also I'd suggest to bind Ctrl-up/down 
as standard for single line scrolling. This is really missing, 
the more as long as sliders dont work so well ;)

Thanks,

-- grischka

Re: vertical scrollbar error on MS Windows

[Stefan Monnier]

> Here is another fix for the scrollbars.  From the approach
> it calculates the thumb length once on mouse down and 
> then leaves bar parameters alone during dragging.

This approach suffers from the same problems.
I only know of two simple solutions:
1 - set the thumb size to 0 while dragging.
2 - make the thumb size "fixed" and arrange that when it hits bottom,
    then the start of the thumb corresponds to position point-max.

The best solution is to change the toolkit such that it doesn't hide from
you the information that the mouse was moved past the bottom of the
scrollbar.  This is what Xaw does.  It's generally trivial to do,
technically, but it usually hits a human brick wall.


        Stefan

Re: vertical scrollbar error on MS Windows

[grischka]

Stefan Monnier wrote:

> > Here is another fix for the scrollbars.  From the approach
> > it calculates the thumb length once on mouse down and 
> > then leaves bar parameters alone during dragging.
> 
> This approach suffers from the same problems.

Not shure what you mean, works for me. 

> I only know of two simple solutions:
> 1 - set the thumb size to 0 while dragging.

Too much activity on the peripheral visuals for my taste.

> 2 - make the thumb size "fixed" and arrange that when it hits bottom,
>     then the start of the thumb corresponds to position point-max.

If you change the start position then you constantly need 
to watch it whether it's still there where you left it off. 

> The best solution is to change the toolkit such that it doesn't hide from
> you the information that the mouse was moved past the bottom of the
> scrollbar.  This is what Xaw does.  It's generally trivial to do,
> technically, but it usually hits a human brick wall.
> 
> 
>         Stefan

You mean subclass the control? Shure, why not. 

If only there wasn't one more general problem which Xaw 
(if thats what I figure) does not have because it doesn't 
have a slider, really. That is with a slider if you can 
grab it at the lower end, it means you end up pulling 
below the frame bottom and outside the monitor if the 
slider gets shorter during dragging. So ...

-- grischka

Re: vertical scrollbar error on MS Windows

[Stephan Hennig]

Lennart Borgman (gmail) schrieb:
> Kim F. Storm wrote:
>> 
>> Can you -- and other W32 users -- please try out the latest CVS
>> and tell me ASAP if there are still _severe_ problems with it.
>> 
> 
> I have uploaded a new unpatched version Emacs+EmacsW32 for those who 
> want to test:
> 
>   http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl

I've done some tests with that version now (This is GNU Emacs 22.0.93.1
(i386-mingw-nt5.1.2600) of 2007-02-19 on LENNART-69DE564).

Scrolling has indeed improved.  The erratic up and down movement of the
buffer while dragging the scrollbar in _one_ direction seems to has gone
away.

Still there are some problems:

(i) You cannot scroll to the end of a buffer any more.  There simply is
no end, i.e., the longer you drag the scrollbar to the bottom of the
frame the smaller the scrollbar gets and buffer contents moves out of
the buffer ending up with an empty buffer.


(ii) If you click on the scrollbar (without dragging) old buggy
behaviour was that the scrollbar moves up after pressing left mouse
button.  New behaviour is to move _down_ after pressing the left mouse
button.  This bug seems to depend on which part of a buffer is visible
and on frame size:

*  Start Emacs with emacs -Q.
*  In a ca. 40 line high frame visit etc\DEBUG.
*  Move the scrollbar past 50% of the buffer.
*  Click the scrollbar with <mouse-1>.  The scrollbar moves down.
*  In a ca. 90 line heigh frame the effect can only be observed
   after moving the scrollbar past 75% of the buffer.


(iii) Visiting etc\DEBUG, I can't manage to scroll the buffer down with
the scrollbar so that the top most line becomes an empty line.  Instead
when the second line of a buffer is an empty line and you're dragging
the scrollbar down slowly, the third line suddenly gets the top most
line.  That is, you can't scroll line-wise through a buffer.

The problem with this is less that the top most line can't become an
empty line, but that the whole buffer scrolls at different speeds.
Sometimes it's line-wise and sometimes it's two lines at once.  This is
confusing.

Best regards,
Stephan Hennig

Re: vertical scrollbar error on MS Windows

[Jason Rumney]

Stephan Hennig wrote:
> I've done some tests with that version now (This is GNU Emacs 22.0.93.1
> (i386-mingw-nt5.1.2600) of 2007-02-19 on LENNART-69DE564).
>
> Scrolling has indeed improved.  The erratic up and down movement of the
> buffer while dragging the scrollbar in _one_ direction seems to has gone
> away.
>
> Still there are some problems:
>   

It seems that the latest change reverted the previous buggy behaviour to 
earlier buggy behaviour, where the scrollbar handle resizes as you scroll.

If this behaviour is generally preferred to the previous behaviour, then 
we should leave it like this until after the release. Experience has 
shown that it is going to take major changes in the way we perform our 
scroll-bar related calculations to make an improvement in this area 
without breaking it in some other way.

Re: vertical scrollbar error on MS Windows

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> Stephan Hennig wrote:
>> I've done some tests with that version now (This is GNU Emacs 22.0.93.1
>> (i386-mingw-nt5.1.2600) of 2007-02-19 on LENNART-69DE564).
>>
>> Scrolling has indeed improved.  The erratic up and down movement of the
>> buffer while dragging the scrollbar in _one_ direction seems to has gone
>> away.

Good!  That was the main problem I was trying to solve.

>>
>> Still there are some problems:
>>   
>
> It seems that the latest change reverted the previous buggy behaviour
> to earlier buggy behaviour, where the scrollbar handle resizes as you
> scroll.

Only when the handle is near the end of the buffer -- to be able to
actually reach the end of the buffer.

As Stephan noted, it may scroll too far (making the bottom line scroll
out of view) - but that's actually the normal Emacs behaviour on X!

> If this behaviour is generally preferred to the previous behaviour,
> then we should leave it like this until after the release. Experience
> has shown that it is going to take major changes in the way we perform
> our scroll-bar related calculations to make an improvement in this
> area without breaking it in some other way.

Indeed - this is not the time to "really fix it".

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: vertical scrollbar error on MS Windows

[Stephan Hennig]

Jason Rumney schrieb:


> If this behaviour is generally preferred to the previous behaviour,

I'd prefer the current behaviour.


> then we should leave it like this until after the release. Experience
> has shown that it is going to take major changes in the way we
> perform our scroll-bar related calculations to make an improvement in
> this area without breaking it in some other way.

FWIW, the items in my list were given in reverse priority order,
accidentally.  That is, I think item (iii) is the most annoying bug
since it instantly gives you a non-smooth scrolling experience.  I have
no idea if that item were easy to fix at the current state.

Best regards,
Stephan Hennig

Re: vertical scrollbar error on MS Windows

[Kim F. Storm]

Stephan Hennig <mailing_list@arcor.de> writes:

> FWIW, the items in my list were given in reverse priority order,
> accidentally.  That is, I think item (iii) is the most annoying bug
> since it instantly gives you a non-smooth scrolling experience.  I have
> no idea if that item were easy to fix at the current state.

That is the hardest problem to fix ...

Emacs scrolling counts in characters, not lines.
So scrolling an empty line means scrolling 1 character, which
is typically less than the "minimum scroll unit".

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: vertical scrollbar error on MS Windows

[Stefan Monnier]

> (i) You cannot scroll to the end of a buffer any more.  There simply is
> no end, i.e., the longer you drag the scrollbar to the bottom of the
> frame the smaller the scrollbar gets and buffer contents moves out of
> the buffer ending up with an empty buffer.

This is not a bug.  You may find it surprising, but it's the way
thumb-scrolling was meant to behave under Emacs.


        Stefan

Re: vertical scrollbar error on MS Windows

[Stefan Monnier]

>> > Here is another fix for the scrollbars.  From the approach
>> > it calculates the thumb length once on mouse down and
>> > then leaves bar parameters alone during dragging.
>> This approach suffers from the same problems.
> Not shure what you mean, works for me.

The other code works as well.  But there are problems in some circumstances.

BTW, if changing the thumb during drag-scroll causes jitter, an alternative
to "no resize" is to only allow resize in one direction (typically: only
shrink).

>> 2 - make the thumb size "fixed" and arrange that when it hits bottom,
>> then the start of the thumb corresponds to position point-max.

> If you change the start position then you constantly need
> to watch it whether it's still there where you left it off.

No, you don't understand what I mean.  Just change the way thumb positions
are mapped to buffer positions.  Say your scrollbar has size 130, and you
choose thumbsize of 30, then position 0-30 is "window-start == point-min",
and position 100-130 is "window-start == point-max".

> If only there wasn't one more general problem which Xaw 
> (if thats what I figure) does not have because it doesn't 
> have a slider, really. That is with a slider if you can 
> grab it at the lower end, it means you end up pulling 
> below the frame bottom and outside the monitor if the 
> slider gets shorter during dragging. So ...

If I understand correctly what you mean, then the Xaw behavior is exactly
what we want.  That leaves it to the application to decide whether the thumb
can "slide past the end" or not.

A slider that slides past the end is not a problem, really.  You seem to
dislike it, could you explain why?


        Stefan

Re: vertical scrollbar error on MS Windows

[grischka]

> > > > Here is another fix for the scrollbars ...
> > > This approach suffers from the same problems.
> > Not shure what you mean, works for me.
> The other code works as well.  But there are problems 
> in some circumstances.

Problems with the other code? May be.

> If I understand correctly what you mean, then the Xaw behavior is exactly
> what we want. That leaves it to the application to decide whether the
> thumb can "slide past the end" or not.

Xaw certainly has its nostalgic charme with its own behaviour 
and design. But, no, I don't think you want Xaw behaviour with 
windows scrollbars. Not even with GTK scrollbars, really. 

> A slider that slides past the end is not a problem, really.
> You seem to dislike it, could you explain why?

Actually I don't know what it means. An end where it can 
go past is not the end, no?

Ah, okay, maybe you see it differently. Such that the slider 
does not shrink on bottom, but actually slips into some 
slit in the frame. Is it that?

-- grischka

Re: vertical scrollbar error on MS Windows

[David Kastrup]

"grischka" <grishka@gmx.de> writes:

> Xaw certainly has its nostalgic charme with its own behaviour 
> and design. But, no, I don't think you want Xaw behaviour with 
> windows scrollbars. Not even with GTK scrollbars, really. 

I'd want to.  I have asked on the GTK+ developer list for it (without
any response), and I compile my Emacs --with-gtk
--without-toolkit-scrollbars (add or take a hyphen, can't remember)
since anything but Athena behavior (and the resulting Lucid toolbars
_have_ Athena behavior) is so much less functional as to be crippled.

Scroll back and forth without moving the mouse in between?  Blank.
Scroll a variable amount with one click?  Blank.
Scroll back and forth a variable amount?  Double blank.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: vertical scrollbar error on MS Windows

[Stefan Monnier]

>> If I understand correctly what you mean, then the Xaw behavior is exactly
>> what we want. That leaves it to the application to decide whether the
>> thumb can "slide past the end" or not.

> Xaw certainly has its nostalgic charme with its own behaviour
> and design.  But, no, I don't think you want Xaw behaviour with
> windows scrollbars.  Not even with GTK scrollbars, really.

I sure do.

>> A slider that slides past the end is not a problem, really.
>> You seem to dislike it, could you explain why?

> Actually I don't know what it means.  An end where it can 
> go past is not the end, no?

So you don't like it because .... you don't know what it means?
Why would you want to "know what it means"?

> Ah, okay, maybe you see it differently. Such that the slider
> does not shrink on bottom, but actually slips into some
> slit in the frame. Is it that?

A scrollbar is nothing more than a bunch of pixels that give you some rough
idea of where you are (and how much of the rest there is left to see), along
with some way to move with the use of a mouse.

I believe that confining oneself strictly to some analogy to the physical
world is just plain dumb.  What's the benefit, concretely?  No user has ever
complained that she doesn't understand how Emacs scrollbars work just
because they "slide off the end".  When the thumb slides off the end, all
users know immediately that it "has slid off the end": they understand it
completely intuitively.  Only GUI-nitpickers get annoyed that it doesn't
conform to some model.


        Stefan

Re: vertical scrollbar error on MS Windows

[grischka]

Stefan Monnier wrote:

> A scrollbar is nothing more than a bunch of pixels that give
> you some rough idea of where you are (and how much of the
> rest there is left to see), along with some way to move with
> the use of a mouse.

Sounds like a somehow applicable description of scrolling
in emacs, to be honest.

> I believe that confining oneself strictly to some analogy to the physical
> world is just plain dumb. What's the benefit, concretely? No user has ever
> complained that she doesn't understand how Emacs scrollbars work just
> because they "slide off the end".  When the thumb slides off the end, all
> users know immediately that it "has slid off the end": they understand it
> completely intuitively.  Only GUI-nitpickers get annoyed that it doesn't
> conform to some model.

I have my doubts whether everybody sees it as you see it. 
As you say one is not confined to one analogy exclusively. 
Also I would not trust a developer with such things anyway.

Other than that I'm still curious to see all that work with 
the intuitive Xaw features added on the scrollbar from the 
other OS.

-- grischka

Re: vertical scrollbar error on MS Windows

[grischka]

David Kastrup wrote:

> ... since anything but Athena behavior (and the resulting Lucid toolbars
> _have_ Athena behavior) is so much less functional as to be crippled.

> Scroll back and forth without moving the mouse in between?  Blank.
> Scroll a variable amount with one click?  Blank.
> Scroll back and forth a variable amount?  Double blank.

Yes, not bad. Aside from personal preference, I'm all pro 
to keep up variety in GUI culture.

-- grischka

Re: vertical scrollbar error on MS Windows

[Lennart Borgman (gmail)]

grischka wrote:

> Yes, not bad. Aside from personal preference, I'm all pro 
> to keep up variety in GUI culture.


As long as it is very easy to change (just a few seconds for the user 
for simple things, a some minutes for more complicated things) it is 
good. When it takes longer I doubt that variety in GUI is that good.

But I believe it is possible to have big variation with such boundaries. 
But it takes work to bring things together.

Re: vertical scrollbar error on MS Windows

[Stefan Monnier]

> Other than that I'm still curious to see all that work with 
> the intuitive Xaw features added on the scrollbar from the 
> other OS.

Just to make things clear: I have not talked about any of the user-level
features of the Xaw scrollbar in this thread.

I only referred to Xaw w.r.t its programmer-level behavior: it is the only
toolkit I know which does not hide from the program the fact that the user
is attempting to move the thumb off the end, thus making it possible for the
program to let the thumb slide off the end (while also making it possible to
disallow it).


        Stefan

Re: vertical scrollbar error on MS Windows

[David Kastrup]

"grischka" <grishka@gmx.de> writes:

> David Kastrup wrote:
>
>> ... since anything but Athena behavior (and the resulting Lucid toolbars
>> _have_ Athena behavior) is so much less functional as to be crippled.
>
>> Scroll back and forth without moving the mouse in between?  Blank.
>> Scroll a variable amount with one click?  Blank.
>> Scroll back and forth a variable amount?  Double blank.
>
> Yes, not bad. Aside from personal preference, I'm all pro 
> to keep up variety in GUI culture.

Not being able to do things is not variety.  Variety is being able to
do them in different ways.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum