Gtk scrollbar: thumb too short

Gtk scrollbar: thumb too short

[Kai Großjohann]

I understand why the scrollbar thumb is shorter than I think it
should be: to allow for placing the last line of the buffer in the
top line of the window.

But still, I'm not so happy with the current look of the scrollbar.
It confuses me quite a bit.  Is there no way to make the thumb extend
to the bottom of the scrollbar area when end of buffer is visible, and
yet to also allow scrolling further down so that the last line of the
buffer can be moved to the top of the window?
-- 
A preposition is not a good thing to end a sentence with.

Re: Gtk scrollbar: thumb too short

[Jan D.]

> I understand why the scrollbar thumb is shorter than I think it
> should be: to allow for placing the last line of the buffer in the
> top line of the window.
> 
> But still, I'm not so happy with the current look of the scrollbar.
> It confuses me quite a bit.  Is there no way to make the thumb extend
> to the bottom of the scrollbar area when end of buffer is visible, and
> yet to also allow scrolling further down so that the last line of the
> buffer can be moved to the top of the window?

Not really.  The code in Emacs does not specify the length of the
thumb, GTK calculates it.  Emacs tells GTK how big the buffer is, how
big a page is and where we are in the buffer.

When GTK decides that the thumb extends to the bottom it will not
emit events for anymore downwards motion with the mouse, only upwards.

The current behaviour is the same as for Emacs compiled with Motif.
To get the effect you want Emacs would have to write its own
scroll bar.  The native scroll bar does indeed do what you want.

The advantages of being able to scroll so that the last line can be moved
to the top can be questioned though.  It is not something other applications
do.  Usually when the the last line is visible the thumb is at the bottom
and you can not scroll so that the last line is moved to the top.
But there is explicit code in Emacs for this behaviour so I figured
that it had been decided some time ago.  It should perhaps be a
settable customization?

	Jan D.

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

> The current behaviour is the same as for Emacs compiled with Motif.
> To get the effect you want Emacs would have to write its own
> scroll bar.  The native scroll bar does indeed do what you want.

The Xaw3d scrollbar also suffers from the problem.  I have some
hacks to partly work around it in the code, and I have a patch
to Xaw3d which solves the problem (after all, Xaw does not suffer from
this problem), but I still haven't heard of any distrib using the patch.

> The advantages of being able to scroll so that the last line can be moved
> to the top can be questioned though.  It is not something other applications
> do.  Usually when the the last line is visible the thumb is at the bottom
> and you can not scroll so that the last line is moved to the top.
> But there is explicit code in Emacs for this behaviour so I figured
> that it had been decided some time ago.  It should perhaps be a
> settable customization?

Actually, this is also difficult to do.  What is the window-start
position that ensures that point-max is visible ?  The only
safe choice is when window-start == point-max.


	Stefan

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    But still, I'm not so happy with the current look of the scrollbar.
    It confuses me quite a bit.  Is there no way to make the thumb extend
    to the bottom of the scrollbar area when end of buffer is visible, and
    yet to also allow scrolling further down so that the last line of the
    buffer can be moved to the top of the window?

Perhaps we could have the thumb "move off the bottom" of the scroll bar,
so that when ZV is at the top of the screen, the thumb is almost invisible.
I don't know whether this would be convenient to use; perhaps that
depends on many little details of the UI of the scroll bar.
For xterm-style mouse-2, it would be convenient if it grabbed the mouse
so that you could easily scroll the thumb beyond the bottom by moving
the mouse beyond the bottom.

Re: Gtk scrollbar: thumb too short

[Jan D.]

Stefan Monnier wrote:

>>The advantages of being able to scroll so that the last line can be moved
>>to the top can be questioned though.  It is not something other applications
>>do.  Usually when the the last line is visible the thumb is at the bottom
>>and you can not scroll so that the last line is moved to the top.
>>But there is explicit code in Emacs for this behaviour so I figured
>>that it had been decided some time ago.  It should perhaps be a
>>settable customization?
> 
> 
> Actually, this is also difficult to do.  What is the window-start
> position that ensures that point-max is visible ?  The only
> safe choice is when window-start == point-max.

When Emacs tells the different scroll bar implementations to adjust the thumb, 
it gives the size of the buffer (whole), the position of the top line 
(position) displayed, and the amount displayed in the window (portion).  All 
this in characters.  So one can figure out if the bottom is visible.

	Jan D.

Re: Gtk scrollbar: thumb too short

[Jan D.]

Richard Stallman wrote:
>     But still, I'm not so happy with the current look of the scrollbar.
>     It confuses me quite a bit.  Is there no way to make the thumb extend
>     to the bottom of the scrollbar area when end of buffer is visible, and
>     yet to also allow scrolling further down so that the last line of the
>     buffer can be moved to the top of the window?
> 
> Perhaps we could have the thumb "move off the bottom" of the scroll bar,
> so that when ZV is at the top of the screen, the thumb is almost invisible.
> I don't know whether this would be convenient to use; perhaps that
> depends on many little details of the UI of the scroll bar.
> For xterm-style mouse-2, it would be convenient if it grabbed the mouse
> so that you could easily scroll the thumb beyond the bottom by moving
> the mouse beyond the bottom.

It does depend on the UI details.  It could be done by grabbing the mouse 
(assuming you can know when to do this), but what about clicking on the arrows 
(line down) or the trough (page down)?  Then one would have to translate 
coordinates to match with the scroll bar window parts and other difficult 
things.  Its almost reimplementing the whole scroll bar logic without having 
the benefit of the scroll bars internal data (size and position of arrows for 
example).

	Jan D.

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

> Stefan Monnier wrote:
> 
> >>The advantages of being able to scroll so that the last line can be moved
> >>to the top can be questioned though.  It is not something other applications
> >>do.  Usually when the the last line is visible the thumb is at the bottom
> >>and you can not scroll so that the last line is moved to the top.
> >>But there is explicit code in Emacs for this behaviour so I figured
> >>that it had been decided some time ago.  It should perhaps be a
> >>settable customization?
> > 
> > 
> > Actually, this is also difficult to do.  What is the window-start
> > position that ensures that point-max is visible ?  The only
> > safe choice is when window-start == point-max.
> 
> When Emacs tells the different scroll bar implementations to adjust the thumb,
> it gives the size of the buffer (whole), the position of the top line
> (position) displayed, and the amount displayed in the window (portion).  All
> this in characters.  So one can figure out if the bottom is visible.

But the potion is not constant and cannot be determined without
first rendering the relevant part of the buffer.


	Stefan

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    > I understand why the scrollbar thumb is shorter than I think it
    > should be: to allow for placing the last line of the buffer in the
    > top line of the window.
    > 
    > But still, I'm not so happy with the current look of the scrollbar.
    > It confuses me quite a bit.  Is there no way to make the thumb extend
    > to the bottom of the scrollbar area when end of buffer is visible, and
    > yet to also allow scrolling further down so that the last line of the
    > buffer can be moved to the top of the window?

    Not really.  The code in Emacs does not specify the length of the
    thumb, GTK calculates it.  Emacs tells GTK how big the buffer is, how
    big a page is and where we are in the buffer.

What happens if the app specifies a position that is less than one
page away from the end?  Is that considered invalid?

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.

    When GTK decides that the thumb extends to the bottom it will not
    emit events for anymore downwards motion with the mouse, only upwards.

Perhaps GTK should have an option so the app can let the thumb move
further down.  What do people think of that?

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

>     When GTK decides that the thumb extends to the bottom it will not
>     emit events for anymore downwards motion with the mouse, only upwards.
> 
> Perhaps GTK should have an option so the app can let the thumb move
> further down.  What do people think of that?

That would solve the problem.  Xaw behaves that way by default,
but GTK, Motif and Xaw3d don't (and don't seem to have an option
right now for it).


	Stefan

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Wed, 2003-03-26 at 22:29, Richard Stallman wrote:
>     > I understand why the scrollbar thumb is shorter than I think it
>     > should be: to allow for placing the last line of the buffer in the
>     > top line of the window.
>     > 
>     > But still, I'm not so happy with the current look of the scrollbar.
>     > It confuses me quite a bit.  Is there no way to make the thumb extend
>     > to the bottom of the scrollbar area when end of buffer is visible, and
>     > yet to also allow scrolling further down so that the last line of the
>     > buffer can be moved to the top of the window?
> 
>     Not really.  The code in Emacs does not specify the length of the
>     thumb, GTK calculates it.  Emacs tells GTK how big the buffer is, how
>     big a page is and where we are in the buffer.
> 
> What happens if the app specifies a position that is less than one
> page away from the end?  Is that considered invalid?
> 
> 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.
>
>     When GTK decides that the thumb extends to the bottom it will not
>     emit events for anymore downwards motion with the mouse, only upwards.
> 
> Perhaps GTK should have an option so the app can let the thumb move
> further down.  What do people think of that?

Thoughts here, in no particular order:

 * I've always found the emacs behavior with respect to the end of the
   buffer quite confusing personally... I think it would be far
   less confusing if the region that was scrolled was actually
   confined to the lines of the buffer (or maybe lines in buffer + 1)

   It's very easily in emacs's default configuration currently to 
   accidentally create text files with lots of trailing blank lines
   since there is no visual differentiation between blank lines and
   overscrolled space.

   (Emacs-21.2 with Xaw3d seems to be just buggy ... if the user drags
   the thumb of the scrollbar past the end of the buffer it shrinks
   to a smaller size and doesn't come back.)

 * Allowing dragging the scrollbar thumb past the end of the 
   trough is something I'm quite hesitant to do:
  
    - It will look like a bug to the user
    - Some themes may not be able to handle such a case nicely (think
      of a theme where the stepper arrows are round circles in the
      trough instead of being as wide as the trough ... in that
      case the thumb can't simply be truncated by the stepper arrow)

 * There have been some somewhat similar requests; Gnumeric (I've
   CC'ed Jody Goldberg in case he has comments) goes to some extensive
   hack lengths so that you can click on the down arrow in the scrollbar
   and add extra blank lines. (You can also extend the area by
   cursoring past the ends of the buffer.) However, differing from the
   Emacs behavior:
 
    - The extra blank lines actually extend the scrollable space - that
      is, the thumb is always confined to the trough, it just shrinks
      to indicate the longer scrollbar space.

    - When you scroll back up, the extra space vanishes.

   I wonder if we added some clean option to GTK+ to allow this 
   behavior, whether it would satisfy the requirements of Emacs? 
   The main difference is that you can't, by dragging the scrollbar,
   position past the end of the buffer. You would need to do 
   it by clicking on the down arrow (middle button goes down a page),
   or by keyboard commands such as C-l.
   
   (Note that Emacs could already implement this behavior for handling
   programmatic overscrolling already ... it's only the clicking
   on the down-arrow part that requires hacks in gnumeric.)
 
Regards,
                                                 Owen

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

>  * I've always found the emacs behavior with respect to the end of the
>    buffer quite confusing personally... I think it would be far
>    less confusing if the region that was scrolled was actually
>    confined to the lines of the buffer (or maybe lines in buffer + 1)

Less confusing but pretty damn hard.  I'll implement it as soon as you
provide me with a moderately efficient function F that maps from
top-of-the-scrollbar-position (in % of the scrollbar size) to
window-start-position (in characters) such that F(100%) ensures
that (point-max) is visible.

Of course, if the last char of the buffer is a large image, the behavior
will be quite different from the case where the last 100KB of the buffer
are invisible.  Which is where the "moderately efficient" constraint
becomes relevant.

>    (Emacs-21.2 with Xaw3d seems to be just buggy ... if the user drags
>    the thumb of the scrollbar past the end of the buffer it shrinks
>    to a smaller size and doesn't come back.)

Could you describe the bug more precisely.  I don't expect the behavior
to be perfect, but "doesn't come back" sounds serious (unless you're just
talking about the size of the thumb: it only decreases while you drag
to avoid nasty "meta-stable" flicker, so the size will only be reset to
the proper value when the drag is over).


	Stefan

Re: Gtk scrollbar: thumb too short

[Andreas Schwab]

Owen Taylor <otaylor@redhat.com> writes:

|> Thoughts here, in no particular order:
|> 
|>  * I've always found the emacs behavior with respect to the end of the
|>    buffer quite confusing personally... I think it would be far
|>    less confusing if the region that was scrolled was actually
|>    confined to the lines of the buffer (or maybe lines in buffer + 1)

I find this behaviour very convenient when scrolling through the buffer,
because the bottom line before scrolling is always
next-screen-context-lines down the top after scrolling.  This makes it
very easy to continue reading, and it is consistent with the behaviour of
vi and less.

|>    It's very easily in emacs's default configuration currently to 
|>    accidentally create text files with lots of trailing blank lines
|>    since there is no visual differentiation between blank lines and
|>    overscrolled space.

Use indicate-empty-lines.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Gtk scrollbar: thumb too short

[Jan D.]

Andreas Schwab wrote:
> Owen Taylor <otaylor@redhat.com> writes:
> 
> |> Thoughts here, in no particular order:
> |> 
> |>  * I've always found the emacs behavior with respect to the end of the
> |>    buffer quite confusing personally... I think it would be far
> |>    less confusing if the region that was scrolled was actually
> |>    confined to the lines of the buffer (or maybe lines in buffer + 1)
> 
> I find this behaviour very convenient when scrolling through the buffer,
> because the bottom line before scrolling is always
> next-screen-context-lines down the top after scrolling.  This makes it
> very easy to continue reading, and it is consistent with the behaviour of
> vi and less.

Good point.  This is an advantage I haven't thought of.  The Emacs behaviour 
makes perfect sense, other applications should adopt it instead of the other 
way around.

	Jan D.

Re: Gtk scrollbar: thumb too short

[Jan D.]

Richard Stallman wrote:
>     > I understand why the scrollbar thumb is shorter than I think it
>     > should be: to allow for placing the last line of the buffer in the
>     > top line of the window.
>     > 
>     > But still, I'm not so happy with the current look of the scrollbar.
>     > It confuses me quite a bit.  Is there no way to make the thumb extend
>     > to the bottom of the scrollbar area when end of buffer is visible, and
>     > yet to also allow scrolling further down so that the last line of the
>     > buffer can be moved to the top of the window?
> 
>     Not really.  The code in Emacs does not specify the length of the
>     thumb, GTK calculates it.  Emacs tells GTK how big the buffer is, how
>     big a page is and where we are in the buffer.
> 
> What happens if the app specifies a position that is less than one
> page away from the end?  Is that considered invalid?

Not invalid, but the position is silently changed to be a page away from the 
end.  GTK scroll bars adjust position values to be in the interval
[minimum value for the scroll bar, maximum value - one page size]

> 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.

As the native scroll bars do?  The disadvantage is that then the thumb size in 
relation to the scroll bar size looses the connection of how much of the buffer 
you are seeing w.r.t. the size of the buffer.  I don't think that is a big 
deal.  I am quite happy with the GTK/Motif way in Emacs also.

>     When GTK decides that the thumb extends to the bottom it will not
>     emit events for anymore downwards motion with the mouse, only upwards.
> 
> Perhaps GTK should have an option so the app can let the thumb move
> further down.  What do people think of that?

That would be nice.

	Jan D.

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    It does depend on the UI details.  It could be done by grabbing the mouse 
    (assuming you can know when to do this), but what about clicking on the arrows 
    (line down) or the trough (page down)?

The cleanest way to do this is by changing the scroll bar
implementation, giving it a feature of allowing position values all
the way up to the size value.

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Thu, 2003-03-27 at 11:50, Andreas Schwab wrote:
> Owen Taylor <otaylor@redhat.com> writes:
> 
> |> Thoughts here, in no particular order:
> |> 
> |>  * I've always found the emacs behavior with respect to the end of the
> |>    buffer quite confusing personally... I think it would be far
> |>    less confusing if the region that was scrolled was actually
> |>    confined to the lines of the buffer (or maybe lines in buffer + 1)
> 
> I find this behaviour very convenient when scrolling through the buffer,
> because the bottom line before scrolling is always
> next-screen-context-lines down the top after scrolling.  This makes it
> very easy to continue reading, and it is consistent with the behaviour of
> vi and less.

Hmm, the default configuration of less seems to clamp to the end
of the buffer for SPACE, though it looks probably changeable from
the man page. Yes, it's consistent with vi.

There is a definite tension between a nice GUI and acting nicely for
keynav... to some extent, of course, the character-based rather than
line based nature of the emacs scrollbar already makes it far from
ideal for a GUI.

I wouldn't disagree that there are some definite advantages to the
current system, but it is going to mean a confusing scrollbar in
one way or the other.

> |>    It's very easily in emacs's default configuration currently to 
> |>    accidentally create text files with lots of trailing blank lines
> |>    since there is no visual differentiation between blank lines and
> |>    overscrolled space.
> 
> Use indicate-empty-lines.

Note the "default configuration" caveat. As I was writing the above, I
thought "I bet there is some way to change this, it's Emacs after all"

Regards,
                                             Owen

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Thu, 2003-03-27 at 11:30, Stefan Monnier wrote:
> >  * I've always found the emacs behavior with respect to the end of the
> >    buffer quite confusing personally... I think it would be far
> >    less confusing if the region that was scrolled was actually
> >    confined to the lines of the buffer (or maybe lines in buffer + 1)
> 
> Less confusing but pretty damn hard.  I'll implement it as soon as you
> provide me with a moderately efficient function F that maps from
> top-of-the-scrollbar-position (in % of the scrollbar size) to
> window-start-position (in characters) such that F(100%) ensures
> that (point-max) is visible.
> 
> Of course, if the last char of the buffer is a large image, the behavior
> will be quite different from the case where the last 100KB of the buffer
> are invisible.  Which is where the "moderately efficient" constraint
> becomes relevant.

Well, if _displaying_ the last page of text can be done with 
reasonable efficiency, you should also be to compute this quantity
with reasonable efficiency.... you just start from the end, and
scan backwards for newlines and compute the height of each line
until you get enough pixels. Then you have to recompute 
(queue a recomputation) any time there is a change in the 
buffer that affects those lines.

But yes, that's probably reasonably complex to implement and there 
is no real bound on the amount of text you might have to look at and lay
out to compute this quantity.

Frankly, I tend to turn off or just not look at the scrollbar because
these same issues make it behave in a confusing manner in general.
(Presumably, if you have a large chunks of hidden text anywhere in
your document, the scrollbar will go whacky.)

While writing text editors with pixel based scrollbars is a subject
with lots of prior art, I'm under no illusions that Emacs could be
switched over without huge changes both to its code and to its
efficiency.

> >    (Emacs-21.2 with Xaw3d seems to be just buggy ... if the user drags
> >    the thumb of the scrollbar past the end of the buffer it shrinks
> >    to a smaller size and doesn't come back.)
> 
> Could you describe the bug more precisely.  I don't expect the behavior
> to be perfect, but "doesn't come back" sounds serious (unless you're just
> talking about the size of the thumb: it only decreases while you drag
> to avoid nasty "meta-stable" flicker, so the size will only be reset to
> the proper value when the drag is over).

I am talking about the size of the thumb. Not only does it not come
back when dragging (which, while it may be intentional, looks 
very much like a bug), it also doesn't come back after you release,
until you move the scrollbar again.

Regards,
                                           Owen

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

> > Could you describe the bug more precisely.  I don't expect the behavior
> > to be perfect, but "doesn't come back" sounds serious (unless you're just
> > talking about the size of the thumb: it only decreases while you drag
> > to avoid nasty "meta-stable" flicker, so the size will only be reset to
> > the proper value when the drag is over).
> 
> I am talking about the size of the thumb. Not only does it not come
> back when dragging (which, while it may be intentional, looks
> very much like a bug), it also doesn't come back after you release,
> until you move the scrollbar again.

Oh, so it's just the "same old".  The first problem is hard to fix,
but the second one should be fixable without too much trouble.


	Stefan

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Thu, 2003-03-27 at 16:42, Luc Teirlinck wrote:
> Owen Taylor wrote:
> 
>    Frankly, I tend to turn off or just not look at the scrollbar because
>    these same issues make it behave in a confusing manner in general.
>    (Presumably, if you have a large chunks of hidden text anywhere in
>    your document, the scrollbar will go whacky.)
> 
> An obvious alternative, assuming no satisfactory solution to your
> problem can be found, is:
> 
> ./configure --without-toolkit-scroll-bars
> 
> The native scrollbar does not have the problem.

By "go whacky", I didn't mean the problem with dragging off the
end, but simply that a character-based scrollbar is going to
inherently act in a confusing matter, especially in the
presence of invisible text.

I tend to suspect that whether the emacs scrollbar is character
based does _not_ depend on whether you are using toolkit
scrollbars, though I'm not about to recompile it to find out :-)

Regards,
                                     Owen

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Owen Taylor wrote:

   Frankly, I tend to turn off or just not look at the scrollbar because
   these same issues make it behave in a confusing manner in general.
   (Presumably, if you have a large chunks of hidden text anywhere in
   your document, the scrollbar will go whacky.)

An obvious alternative, assuming no satisfactory solution to your
problem can be found, is:

./configure --without-toolkit-scroll-bars

The native scrollbar does not have the problem.

   I am talking about the size of the thumb. Not only does it not come
   back when dragging (which, while it may be intentional, looks 
   very much like a bug), it also doesn't come back after you release,
   until you move the scrollbar again.

It also "comes back" if you type in any key or click the mouse.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Owen Taylor wrote:

   By "go whacky", I didn't mean the problem with dragging off the
   end, but simply that a character-based scrollbar is going to
   inherently act in a confusing matter, especially in the
   presence of invisible text.
   I tend to suspect that whether the emacs scrollbar is character
   based does _not_ depend on whether you are using toolkit
   scrollbars, though I'm not about to recompile it to find out :-)

In the presence of tons of invisible text, the native scrollbar
seems to behave like I would expect it to behave.  That may only be
because I have strange expectations, but anyway.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Jody Goldberg]

On Thu, Mar 27, 2003 at 04:18:22PM -0600, Luc Teirlinck wrote:
> 
> In the presence of tons of invisible text, the native scrollbar
> seems to behave like I would expect it to behave.  That may only be
> because I have strange expectations, but anyway.

Gnumeric has received alot of bug reports on this score.  Some
people like the thumb to indicate the visible rows, others want it
to display the visible region.  We have received complaints both
ways.  My preference is for the visible region to provide some
feedback that there is hidden content.

Other areas of contention in Gnumeric's scroll handling are

1) pixel vs row based.  I tend to prefer the latter, but we have
  received complaints that things behave strangely in the presence
  of wide/tall cols/rows.  So there is no consensus.

2) How to indicate current maxima while still permitting a scroll
  'past the end'.  We've chosen to allow dragging only within the
  current region, but permitting the the arrows to scroll further
  and extending the region.  In this case the choice was a simple,
  MS Excel did it this way, and lots of fingers were used to it.  I
  doubt this behavior scales to other application domains.  A quick
  test indicates that neither MS Word nor oowriter have that sort of
  behavior.  They both appear bottom out at the actual end of the
  document.

3) Updating thumb size while dragging
   That just seems irritating.  If a user selcts the bottom of a
   large thumb at the start of the drag then the thumb shrinks they
   end up in an odd position.

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

> I've just thought of an alternative trick to what the Motif code uses:
> use the Xaw system in general, but while dragging force the thumb size
> to 0.  I don't have a patch yet, but it might be a better solution
> than what Motif uses right now.  The only disadvantage compared to
> the native scrollbar should be that the thumb size will be wrong
> while dragging (which it is already anyway).

Here's a sample patch for Motif users.
The main problem with it is that the thumb size is left as 0 when
the mouse button is released and is only reset to its true value
after a cursor movement or a click or .... anything.  But that's
the same problem as what Owen is complaingin about and I have
another patch in the works for it.


	Stefan


Index: xterm.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xterm.c,v
retrieving revision 1.785
diff -u -u -b -r1.785 xterm.c
--- xterm.c	23 Mar 2003 00:59:23 -0000	1.785
+++ xterm.c	27 Mar 2003 23:21:48 -0000
@@ -4105,9 +4109,7 @@
 
 /* Minimum and maximum values used for Motif scroll bars.  */
 
-#define XM_SB_MIN 1
 #define XM_SB_MAX 10000000
-#define XM_SB_RANGE (XM_SB_MAX - XM_SB_MIN)
 
 
 /* Scroll bar callback for Motif scroll bars.  WIDGET is the scroll
@@ -4157,17 +4159,14 @@
 
     case XmCR_DRAG:
       {
-	int slider_size;
-	int dragging_down_p = (INTEGERP (bar->dragging)
-			       && XINT (bar->dragging) <= cs->value);
-
-	/* Get the slider size.  */
+	/* Set the slider size to 0 to make sure we can drag to point-max.  */
 	BLOCK_INPUT;
-	XtVaGetValues (widget, XmNsliderSize, &slider_size, NULL);
+	XmScrollBarSetValues (widget, cs->value, 1,
+			      0, 0, False);
 	UNBLOCK_INPUT;
 
-	whole = XM_SB_RANGE - slider_size;
-	portion = min (cs->value - XM_SB_MIN, whole);
+	whole = XM_SB_MAX - 1;
+	portion = min (cs->value, whole);
 	part = scroll_bar_handle;
 	bar->dragging = make_number (cs->value);
       }
@@ -4382,7 +4381,7 @@
 #ifdef USE_MOTIF
   /* Set resources.  Create the widget.  */
   XtSetArg (av[ac], XtNmappedWhenManaged, False); ++ac;
-  XtSetArg (av[ac], XmNminimum, XM_SB_MIN); ++ac;
+  XtSetArg (av[ac], XmNminimum, 0); ++ac;
   XtSetArg (av[ac], XmNmaximum, XM_SB_MAX); ++ac;
   XtSetArg (av[ac], XmNorientation, XmVERTICAL); ++ac;
   XtSetArg (av[ac], XmNprocessingDirection, XmMAX_ON_BOTTOM), ++ac;
@@ -4576,22 +4575,6 @@
 
 #ifdef USE_MOTIF
 
-  /* We use an estimate of 30 chars per line rather than the real
-     `portion' value.  This has the disadvantage that the thumb size
-     is not very representative, but it makes our life a lot easier.
-     Otherwise, we have to constantly adjust the thumb size, which
-     we can't always do quickly enough: while dragging, the size of
-     the thumb might prevent the user from dragging the thumb all the
-     way to the end.  but Motif and some versions of Xaw3d don't allow
-     updating the thumb size while dragging.  Also, even if we can update
-     its size, the update will often happen too late.
-     If you don't believe it, check out revision 1.650 of xterm.c to see
-     what hoops we were going through and the still poor behavior we got.  */
-  portion = XFASTINT (XWINDOW (bar->window)->height) * 30;
-  /* When the thumb is at the bottom, position == whole.
-     So we need to increase `whole' to make space for the thumb.  */
-  whole += portion;
-
   if (whole <= 0)
     top = 0, shown = 1;
   else
@@ -4607,14 +4590,13 @@
       /* Slider size.  Must be in the range [1 .. MAX - MIN] where MAX
          is the scroll bar's maximum and MIN is the scroll bar's minimum
 	 value.  */
-      size = shown * XM_SB_RANGE;
-      size = min (size, XM_SB_RANGE);
+      size = shown * XM_SB_MAX;
+      size = min (size, XM_SB_MAX);
       size = max (size, 1);
 
       /* Position.  Must be in the range [MIN .. MAX - SLIDER_SIZE].  */
-      value = top * XM_SB_RANGE;
+      value = top * XM_SB_MAX;
       value = min (value, XM_SB_MAX - size);
-      value = max (value, XM_SB_MIN);
 
       XmScrollBarSetValues (widget, value, size, 0, 0, False);
     }

Re: Gtk scrollbar: thumb too short

[Miles Bader]

Owen Taylor <otaylor@redhat.com> writes:
>  * I've always found the emacs behavior with respect to the end of the
>    buffer quite confusing personally... I think it would be far
>    less confusing if the region that was scrolled was actually
>    confined to the lines of the buffer (or maybe lines in buffer + 1)

This is obviously a matter of taste; I would _hate_ it if emacs insisted
on preventing me from scrolling `past the end.'  [There are various
reasons; sometimes I want to hide distracting text, sometimes I want to
align text in adjacent windows a particular way, etc.]

Also note that when the amount of text is less than a full screen,
there's simply no choice -- emacs has to display empty space.  Thus, if
such empty space is confusing, another method must be found to clarify
it.

>    It's very easily in emacs's default configuration currently to 
>    accidentally create text files with lots of trailing blank lines
>    since there is no visual differentiation between blank lines and
>    overscrolled space.

You can turn on `show-trailing-whitespace'.

I don't find this to be a problem, personally (note that the situation
is much better now that `next-line-add-newlines' defaults to nil).

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: Gtk scrollbar: thumb too short

[Miles Bader]

Owen Taylor <otaylor@redhat.com> writes:
> I wouldn't disagree that there are some definite advantages to the
> current system, but it is going to mean a confusing scrollbar in
> one way or the other.

I think the point is that no solution can avoid being confusing in all
situation.  There is no silver bullet.

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: Gtk scrollbar: thumb too short

[Miles Bader]

Miles Bader <miles@lsi.nec.co.jp> writes:
> You can turn on `show-trailing-whitespace'.

Whoops, I meant `indicate-empty-lines'.

[The fringe glyph for this is rather ugly though; it should really be
something a bit less visually prominent...]

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Jody Goldberg wrote:

   Gnumeric has received alot of bug reports on this score.  Some
   people like the thumb to indicate the visible rows, others want it
   to display the visible region.  We have received complaints both
   ways.  My preference is for the visible region to provide some
   feedback that there is hidden content.

Both the native scrollbar and the default (no options to configure)
Xaw3d scroll bars seem to display the "visible region" (if I
understand correctly) and do so, in my judgment, in an accurate way.
One can have all kinds of opinions about other behavior being or not
being preferable, but I would not use the term "whacky" for the
present behavior.

Owen Taylor wrote:

   (Presumably, if you have a large chunks of hidden text anywhere in
   your document, the scrollbar will go whacky.)

Is this a more than a mere "presumption"?

and:

   By "go whacky", I didn't mean the problem with dragging off the
   end, but simply that a character-based scrollbar is going to
   inherently act in a confusing matter, especially in the
   presence of invisible text.

Maybe it "theoretically ought to" inherently act in a confusing
matter, but somehow I do not see it actually happen.  (Except for the
thumb size problem, which does not occur for the native scrollbar.)
Of course, as is clear from Jody's message, one person's "expected
behavior" is going to be another person's confusion and vice versa.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Thu, 2003-03-27 at 21:15, Luc Teirlinck wrote:
> Jody Goldberg wrote:
> 
>    Gnumeric has received alot of bug reports on this score.  Some
>    people like the thumb to indicate the visible rows, others want it
>    to display the visible region.  We have received complaints both
>    ways.  My preference is for the visible region to provide some
>    feedback that there is hidden content.
> 
> Both the native scrollbar and the default (no options to configure)
> Xaw3d scroll bars seem to display the "visible region" (if I
> understand correctly) and do so, in my judgment, in an accurate way.
> One can have all kinds of opinions about other behavior being or not
> being preferable, but I would not use the term "whacky" for the
> present behavior.
> 
> Owen Taylor wrote:
> 
>    (Presumably, if you have a large chunks of hidden text anywhere in
>    your document, the scrollbar will go whacky.)
> 
> Is this a more than a mere "presumption"?
> 
> and:
> 
>    By "go whacky", I didn't mean the problem with dragging off the
>    end, but simply that a character-based scrollbar is going to
>    inherently act in a confusing matter, especially in the
>    presence of invisible text.
> 
> Maybe it "theoretically ought to" inherently act in a confusing
> matter, but somehow I do not see it actually happen.  (Except for the
> thumb size problem, which does not occur for the native scrollbar.)
> Of course, as is clear from Jody's message, one person's "expected
> behavior" is going to be another person's confusion and vice versa.

A) In case it wasn't clear, I am not a Emacs hacker, I am a GTK+ hacker

B) It would be a mistake that assume that anything I say about emacs
   is informed by more than (many thousands of hours of) casual 
   end user use plus theoretical considerations.

C) My main point was that the effect of invisible text on locating the
   end scroll position of the buffer should be roughly the same as
   the effect of it on computing the correct scrollbar size.

   Stefan Monnier seemed to think that invisible text would make
   computing the end scroll position of the scrollbar very hard. 
   That implied to me that Emacs computed scrollbars based on total 
   characters not visible characters; but I didn't research the
   point.

Regards,
                                        Owen

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Owen Taylor wrote:

      Stefan Monnier seemed to think that invisible text would make
      computing the end scroll position of the scrollbar very hard. 
      That implied to me that Emacs computed scrollbars based on total 
      characters not visible characters; but I didn't research the
      point.

In a certain sense that actually seems correct.

I only claim that the actual behavior seems consistent.  It is not at
all clear what the ideal behavior is supposed to be.  It seems to
depend on personal taste.

There are two main ways to "hide" text, selective display and the
"invisible" text and overlay property.  Both seem to behave the same
way.  Selective display is the most convenient to experiment with.

Set scroll-conservatively to 1000 or such, so that lines come into
view one by one.  Take some piece of heavily indented code and do 
M-1 C-x $  Just start scrolling with C-n or the down-arrow key.
Watch the scroll-bar.

If a 

...

line representing invisible text comes into view then everything
depends on the size of the invisible text.  If it represents a large
chunk of invisible code, the effect on the scrollbar is dramatic,
otherwise it is negligible.  In other words, it gives you an idea of
the amount of actual (indented) code you are scrolling through.

Bug or feature?  I do not know whether there is a "correct" answer to
that question.  It depends on what the user is trying to do and on the
user's taste and expectations.  But it seems predictable.  Somehow, it
looks OK to me, but it is very well possible that the only reason why
is that it is the (only) behavior I am used to.  (I seldom get
confronted with invisible text outside of Emacs.)

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Robert J. Chassell]

Miles Bader <miles@gnu.org> wrote

   ... I would _hate_ it if emacs insisted on preventing me from
   scrolling `past the end.'  [There are various reasons; sometimes I
   want to hide distracting text, sometimes I want to align text in
   adjacent windows a particular way, etc.]

I agree. We must able to scroll `past the end.'

The question is

  * How should you display scrolling past the end?

      - In Emacs 21.3 (current CVS):  by displaying the whole thumb,
        until last character of the buffer is in the top line of the
        window.  

        This means that in a short buffer, such as the initial
        *Messages* buffer in a plain Emacs 21.3 started with

            emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

        the thumb does *not* show it is displaying `all' of the
        buffer, but shows the post-end-of-buffer empty lines too.

      - In Emacs 20.7:  by letting the scroll bar `sink' into the
        space below it, so it gets smaller and smaller, until the last
        character of the buffer is in the top line of the window.

I prefer the Emacs 20.7 way of doing it; that way, I don't think of
the thumb as telling me that the buffer is larger than it really is.

(My major use of the thumb and scroll bar is as a reporter; it tells
me where I am in the buffer and how large the buffer is.)

It is worth noting that a buffer is divided into three parts:

  * visible, accessible text

  * invisible text

  * inaccessible text from narrowing

and a window `contains' those three parts as well as 

  * post-eob empty lines

In addition to the question of how to display `scrolling past the
end', we have a question of

  * What fraction of a whole buffer should a thumb show?

      - the visible text portion of the whole buffer, regardless of
        narrowing, that is in the window displaying the buffer?

      - the visible, accessible portion of the whole buffer plus the
        invisible text that is `contained' within the window?

      - the portion of the visible region of the whole buffer that is
        displayed within the window?

I prefer that the thumb show the visible accessible portion of the
whole, that is to say, the part that is accessible either because it
is visible or because it is not hidden by narrowing.

This means that if you make some text invisible, for example by type
`C-c C-t' (hide-body) in outline mode, the thumb grows larger.

Likewise, if you make some text invisible and inaccessible by
narrowing to a smaller region, the thumb grows larger.

This is the way it is done in Emacs 20.7.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Robert Chassell wrote:

   I prefer that the thumb show the visible accessible portion of the
   whole, that is to say, the part that is accessible either because it
   is visible or because it is not hidden by narrowing.

   This means that if you make some text invisible, for example by type
   `C-c C-t' (hide-body) in outline mode, the thumb grows larger.

   Likewise, if you make some text invisible and inaccessible by
   narrowing to a smaller region, the thumb grows larger.

   This is the way it is done in Emacs 20.7.

I believe that there may be some confusion here.  If you make stuff
invisible in such a way that the total amount of text (visible and
invisible), between the position at the top of the screen and the one
at the bottom of the screen, increases, the thumb size increases.  If
you are careful to only make stuff outside the screen invisible,
nothing happens to the thumb.  (Tested in Emacs 20.7, native
scrollbars.)  M-1 C-x $ is a good way to experiment, with text
deliberately indented for he purpose.

In other words, what the thumb seems to measure is the proportion of
total (visible or invisible) text between top and bottom of the screen
compared to the total text in the buffer. 

This seems to be the behavior in Emacs 20.7 with native scrollbars, as
well as in the current 21.3.50 CVS, both with native 
(./configure --without-toolkit-scroll-bars) and with Xaw3d (no options
to configure) scroll bars.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

>    Stefan Monnier seemed to think that invisible text would make
>    computing the end scroll position of the scrollbar very hard. 
>    That implied to me that Emacs computed scrollbars based on total 
>    characters not visible characters; but I didn't research the
>    point.

Yes.  The behavior of the scrollbar in the presence of large chunks of
invisible text is definitely less than perfect.  Same thing with
large images, by the way.  Basically, the scrollbar should be based on
"number of vertical pixels" rather than "number of chars", but
given the current way Emacs is written, it's basically impossible
to do.


	Stefan

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

>   * How should you display scrolling past the end?
> 
>       - In Emacs 21.3 (current CVS):  by displaying the whole thumb,
>         until last character of the buffer is in the top line of the
>         window.  
> 
>         This means that in a short buffer, such as the initial
>         *Messages* buffer in a plain Emacs 21.3 started with
> 
>             emacs -q --no-site-file --eval '(blink-cursor-mode 0)'
> 
>         the thumb does *not* show it is displaying `all' of the
>         buffer, but shows the post-end-of-buffer empty lines too.
> 
>       - In Emacs 20.7:  by letting the scroll bar `sink' into the
>         space below it, so it gets smaller and smaller, until the last
>         character of the buffer is in the top line of the window.
> 
> I prefer the Emacs 20.7 way of doing it; that way, I don't think of
> the thumb as telling me that the buffer is larger than it really is.

It's also the 21.3 behavior, except in Motif.


	Stefan

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Stefan Monnier wrote:

   Yes.  The behavior of the scrollbar in the presence of large chunks of
   invisible text is definitely less than perfect.

You and Owen are probably both right.  This is probably just a case
where I consider a certain behavior to be appropriate for no other
reason than that I have grown used to it.  The current way actually
has some advantages, but it probably does not compensate for the
negatives.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Miles Bader <miles@lsi.nec.co.jp> writes:
> > You can turn on `show-trailing-whitespace'.
> 
> Whoops, I meant `indicate-empty-lines'.
> 
> [The fringe glyph for this is rather ugly though; it should really be
> something a bit less visually prominent...]
> 

Are you talking about the 21.2 fringe glyph (a block) or the new glyph
in CVS head (small dashes) ?

What kind of glyph do you suggest?

BTW, it is still on my to-do list to make the fringe glyphs user
customizable...

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

Re: Gtk scrollbar: thumb too short

[Robert J. Chassell]

Luc Teirlinck <teirllm@dms.auburn.edu> wrote

   I believe that there may be some confusion here.  If you make stuff
   invisible in such a way that the total amount of text (visible and
   invisible), between the position at the top of the screen and the one
   at the bottom of the screen, increases, the thumb size increases.  If
   you are careful to only make stuff outside the screen invisible,
   nothing happens to the thumb.  (Tested in Emacs 20.7, native
   scrollbars.)

I am puzzled.  Using 20.7, when I visit NEWS by typing `C-h n'
(view-emacs-news) and then type `C-c C-t' (hide-body), the thumb grows
bigger.

When I then type `C-c C-a' (show-all), the thumb grows smaller.

I interpret this to mean that the thumb shows the portion of visible
text shown in the window to all the visible text in the buffer.

In any event, I like this policy.

If I remember rightly I configured 20.7 this way:

        ./configure --prefix=/usr/local

(I built Emacs 20.7 a long time ago; perhaps I also added
`--with-type1 --with-sound=yes' to the configuration.)

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

     * I've always found the emacs behavior with respect to the end of the
       buffer quite confusing personally... I think it would be far
       less confusing if the region that was scrolled was actually
       confined to the lines of the buffer (or maybe lines in buffer + 1)

If you mean that it would be impossible for the end of the buffer to
be located above the last line of the window, that would be taking
away a feature that users are accustomed to.  We can't do that.

     * Allowing dragging the scrollbar thumb past the end of the 
       trough is something I'm quite hesitant to do:

	- It will look like a bug to the user
	- Some themes may not be able to handle such a case nicely (think
	  of a theme where the stepper arrows are round circles in the
	  trough instead of being as wide as the trough ... in that
	  case the thumb can't simply be truncated by the stepper arrow)

It isn't a bug, though--and what else should the scroll bar do?
What happens in those themes will be logical, and will show that
the current visible window extends past the end of the text.

	- The extra blank lines actually extend the scrollable space - that
	  is, the thumb is always confined to the trough, it just shrinks
	  to indicate the longer scrollbar space.

In Emacs, these aren't "extra blank lines".  Emacs doesn't extend
the buffer contents to reach the bottom of the window.
The Gnumeric behavior isn't right for Emacs.

The GUI for a program should reflect the data in the program,
not vice versa.

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    > What happens if the app specifies a position that is less than one
    > page away from the end?  Is that considered invalid?

    Not invalid, but the position is silently changed to be a page away from the 
    end.  GTK scroll bars adjust position values to be in the interval
    [minimum value for the scroll bar, maximum value - one page size]

I think GTK should have an option to accept such values
and display them in some sensible way.

    > 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.

    As the native scroll bars do?  The disadvantage is that then the
    thumb size in relation to the scroll bar size looses the
    connection of how much of the buffer you are seeing w.r.t. the
    size of the buffer.

Either we are miscommunicating about something basic, or I disagree.
In what I envision, the visible thumb size would reflect the amount of
real text visible in the window.  As window-start gets closer to
point-max, the amount of visible text decreases, and so should the
thumb size.

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Fri, 2003-03-28 at 10:20, Richard Stallman wrote:
>      * I've always found the emacs behavior with respect to the end of the
>        buffer quite confusing personally... I think it would be far
>        less confusing if the region that was scrolled was actually
>        confined to the lines of the buffer (or maybe lines in buffer + 1)
> 
> If you mean that it would be impossible for the end of the buffer to
> be located above the last line of the window, that would be taking
> away a feature that users are accustomed to.  We can't do that.

Was just an offhand comment :-) I didn't really expect it to be
acted on.

>      * Allowing dragging the scrollbar thumb past the end of the 
>        trough is something I'm quite hesitant to do:
> 
> 	- It will look like a bug to the user
> 	- Some themes may not be able to handle such a case nicely (think
> 	  of a theme where the stepper arrows are round circles in the
> 	  trough instead of being as wide as the trough ... in that
> 	  case the thumb can't simply be truncated by the stepper arrow)
> 
> It isn't a bug, though--and what else should the scroll bar do?
> What happens in those themes will be logical, and will show that
> the current visible window extends past the end of the text.

Just because something makes logical sense doesn't mean it will make
sense to users. But my concern is more:

 - It will be a confusing visual mess.
 - The visual representation won't correspond to the users ability
   to click on the scrollbar. (The ability to click on the arrow
   is not affected by the theme, just the visual representation.)
 - I suspect that many themes will simply not draw it correctly.

> 	- The extra blank lines actually extend the scrollable space - that
> 	  is, the thumb is always confined to the trough, it just shrinks
> 	  to indicate the longer scrollbar space.
> 
> In Emacs, these aren't "extra blank lines".  Emacs doesn't extend
> the buffer contents to reach the bottom of the window.
> The Gnumeric behavior isn't right for Emacs.
> 
> The GUI for a program should reflect the data in the program,
> not vice versa.

I think there is a strong case to be made that the length of the
scrollbar trough is

 MAX (length of document, maximum visible position)

rather than simple the length of the document. Consider the case
where the document is shorter than the screen height. In that case,
there is a strong expectation that the thumb extends the entire
length of the trough, and Emacs does that currently.

If you _didn't_ do that, then you'd have a scrollbar that only
occupies part of the trough but that it was impossible to drag
up and down. While that might make logical sense, it would be
highly confusing.

So if this interpretation of the trough length corresponding
to:

 MAX (length of document, maximum visible position)

is used for documents shorter than the screen, I don't see a
reason why it can't be used for the case of overscrolling as
well. The main difficulty would be when to take the overscrolled
area out of the trough size computation... usually you
want to do it immediately, but when the user is dragging the
scrollbar, probably not until they release the mouse.

To do that with GTK+ currently, is a bit of a hack, you
have to connect to the ::button-release-event signal on the
scrollbar. But I think it would be a reasonable RFE for GTK+
to have some clean way of finding out when the drag finishes.

Regards,
                                       Owen

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Robert Chassell wrote:

   I am puzzled.  Using 20.7, when I visit NEWS by typing `C-h n'
   (view-emacs-news) and then type `C-c C-t' (hide-body), the thumb grows
   bigger.

   When I then type `C-c C-a' (show-all), the thumb grows smaller.

That is because the total (visible and invisible) amount of text on
the screen increases or decreases.  This also seems to happen in
21.3.50, it just is harder to notice.  (C-c C-t seems to take an
awfully long time in Emacs-21.3.50 in the NEWS buffer.)
   
   I interpret this to mean that the thumb shows the portion of visible
   text shown in the window to all the visible text in the buffer.

No, because if you start with a full screen and make all text outside
your screen invisible, nothing happens to the thumb size.  So the
thumb does count invisible text as present in the buffer.

Stefan knows substantially more about the scrollbar than I do.  He
can correct me if I am wrong.  I believe I am right on this particular
issue however.  (We are talking about Emacs20.7, configured with with
./configure --prefix=/usr/local)

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Robert J. Chassell]

Thumb behavior depends on which toolkit you use.

Today's CVS snapshot, Fri, 2003 Mar 28  14:53 UTC
GNU Emacs 21.3.50.253 (i686-pc-linux-gnu)

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

    >         This means that in a short buffer, such as the initial
    >         *Messages* buffer in a plain Emacs 21.3 started with
    > 
    >             emacs -q --no-site-file --eval '(blink-cursor-mode 0)'
    > 
    >         the thumb does *not* show it is displaying `all' of the
    >         buffer, but shows the post-end-of-buffer empty lines too.

    > ....

    > I prefer the Emacs 20.7 way ...

    It's also the 21.3 behavior, except in Motif.

That is true for 21.3 configured like this:

    gcc=gcc-3.2 ./configure --with-type1 --prefix=/usr/local --with-sound=yes

(i.e., with a LUCID tool kit), 

but it is *not* true for 21.3 configured with --with-x-toolkit=gtk

So it is not only that 

   .... The behavior of the scrollbar in the presence of large chunks
   of invisible text is definitely less than perfect.

as you said, but it depends on the toolkit.  <grumble>

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

>     It's also the 21.3 behavior, except in Motif.
> but it is *not* true for 21.3 configured with --with-x-toolkit=gtk

AFAIK 21.3 does not support GTK.  You must be talking about 21.3.50
aka the trunk.

> So it is not only that 
> 
>    .... The behavior of the scrollbar in the presence of large chunks
>    of invisible text is definitely less than perfect.
> 
> as you said, but it depends on the toolkit.  <grumble>

AFAIK the behavior of the scrollbar w.r.t invisible text
is the same for all toolkits (modulo the thumb size).




	Stefan

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Fri, 2003-03-28 at 10:21, Richard Stallman wrote:
>     > What happens if the app specifies a position that is less than one
>     > page away from the end?  Is that considered invalid?
> 
>     Not invalid, but the position is silently changed to be a page away from the 
>     end.  GTK scroll bars adjust position values to be in the interval
>     [minimum value for the scroll bar, maximum value - one page size]
> 
> I think GTK should have an option to accept such values
> and display them in some sensible way.
> 
>     > 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.
> 
>     As the native scroll bars do?  The disadvantage is that then the
>     thumb size in relation to the scroll bar size looses the
>     connection of how much of the buffer you are seeing w.r.t. the
>     size of the buffer.
> 
> Either we are miscommunicating about something basic, or I disagree.
> In what I envision, the visible thumb size would reflect the amount of
> real text visible in the window.  As window-start gets closer to
> point-max, the amount of visible text decreases, and so should the
> thumb size.

This is certainly _also_ a possible interpretation the scrollbar thumb
size:

 n_characters_visible / n_total_characters

is as logical as:

 (n_characters_visible + (factor) * n_dummy_lines) /
 (n_total_characters + (factor) * n_dummy_lines)

But if you take this interpretation then when you "overscroll",
then the scrollbar should simply get smaller, not go off the end
of the scrollbar. 

An observation I'd make is that a scrollbar really encodes two
things:

 - A value
 - A percentage of a total size

If we look at the scrollbar on the screen, we have:

 v = thumb_start / (trough_pixels - thumb_pixels)
 p = thumb_pixels / trough_pixels

For the normal GTK+ case these two quantities are related to the
document size.

 v = start_of_visible / MAX (size_of_visible, size_of_document) - size_of_visible
 p = size_of_visible / MAX (size_of_visible, size_of_document)

Or, in terms of GtkAdjustment parameters

 v = value / (max - page_size)
 p = page_size / max

For what you want in Emacs, v and p are computed differently:

 v = start_of_visible / character_index_of_start_of_last_line
 p = visible_chars / total_chars

What we simply need to do is compute GtkAdjustment parameters that
give these same v and p.

Fixing, say, max = total_characters, then we have:

 max = total_characters
 page_size = max * p = visible_characters
 value = v * (max - page_size) 
       = (start_of_visible / character_index_of_start_of_last_line) * 
         (total_chars - visible_chars)

Now, clearly there are some complexities from the fact that
visible_chars changes as the position changes. But I think the
approach is workable and will be a whole lot less confusing
then some sort of idea of the thumb of the scrollbar going off
the edge of the scrollbar trough.

Regards,
                                              Owen

Re: Gtk scrollbar: thumb too short

[Jan D.]

>> 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.
>
>     As the native scroll bars do?  The disadvantage is that then the
>     thumb size in relation to the scroll bar size looses the
>     connection of how much of the buffer you are seeing w.r.t. the
>     size of the buffer.
>
> Either we are miscommunicating about something basic, or I disagree.
> In what I envision, the visible thumb size would reflect the amount of
> real text visible in the window.  As window-start gets closer to
> point-max, the amount of visible text decreases, and so should the
> thumb size.

It is just a difference in interpretation.  For you a small thumb means
that the number of visible real text is small.

When I see a thumb that is 1/3 of the scroll bar size, I take that to
mean that the buffer size is about 3 times larger than what can be
displayed in a page.  If we should scroll "off the bottom" so that
the thumb becomes 1/10 of the scroll bar size, obviously the buffer
has not become 10 times the size of one page, but rather ten times
larger than the visible real text.

I don't claim that one view is better than the other, it is just
what I am used to, mainly using scroll bars in applications where the
thumb size is practically fixed as long as the content stay the same.

	Jan D.

Re: Gtk scrollbar: thumb too short

[Jan D.]

> I think there is a strong case to be made that the length of the
> scrollbar trough is
>
>  MAX (length of document, maximum visible position)
>
> rather than simple the length of the document. Consider the case
> where the document is shorter than the screen height. In that case,
> there is a strong expectation that the thumb extends the entire
> length of the trough, and Emacs does that currently.

Actually it doesn't for GTK and Motif scroll bars.  If there are
three lines in a buffer and the window can display 25, space is
made at the bottom so that one can scroll those three lines.
We tell the scroll bar that the maximum size is 28 lines
and the page size is 25 (more or less).


> If you _didn't_ do that, then you'd have a scrollbar that only
> occupies part of the trough but that it was impossible to drag
> up and down. While that might make logical sense, it would be
> highly confusing.

If it could not be manipulated that would be bad.

> So if this interpretation of the trough length corresponding
> to:
>
>  MAX (length of document, maximum visible position)
>
> is used for documents shorter than the screen, I don't see a
> reason why it can't be used for the case of overscrolling as
> well. The main difficulty would be when to take the overscrolled
> area out of the trough size computation... usually you
> want to do it immediately, but when the user is dragging the
> scrollbar, probably not until they release the mouse.
>
> To do that with GTK+ currently, is a bit of a hack, you
> have to connect to the ::button-release-event signal on the
> scrollbar. But I think it would be a reasonable RFE for GTK+
> to have some clean way of finding out when the drag finishes.

If GTK had some way to indicate that the user pressed on the arrow it
would be easy to take that into account also.

	Jan D.

Re: Gtk scrollbar: thumb too short

[Robert J. Chassell]

   I don't claim that one view is better than the other ... 

I just tried to move the bottom line of an article shown in the
Mozilla web browser up so I could see it better, and I could not.

User interfaces using that design are broken.

On the other hand, in GNU Emacs W3M mode I was able to view the site
comfortably, using either an instance of Emacs built with
`--with-x-toolkit=gtk' or one without, a LUCID toolkit.  

(The GTK instance has the scroll bar/thumb showing more text than
actually exists in the buffer; but it does handle the other parts of
the interface OK.)

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk scrollbar: thumb too short

[Robert J. Chassell]

Konqueror fails, too.

       I don't claim that one view is better than the other ... 

    I just tried to move the bottom line of an article shown in the
    Mozilla web browser up so I could see it better, and I could not.

I just tried the same on Konqueror using KDE.  Equivalent failure.  

It looks to me that `mainstream' browsers are as lacking of decent
interface design as mainstream desktops that lack `incremental search'
(which Jef Raskin (of Apple Macintosh interface fame) recommends in
his book, `The Humane Interface').

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk scrollbar: thumb too short

[Kim F. Storm]

huug <huug.at.gmane@xs4all.nl> writes:

> > BTW, it is still on my to-do list to make the fringe glyphs user
> > customizable...
> 
> And its position too, I hope. 

Yes, I'm working on placing the fringe between the display margin
and the text area.

>                               Even if it was just a follow-scrollbar..

I don't understand.  What are you suggesting?

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

Re: Gtk scrollbar: thumb too short

[Kim F. Storm]

huug <huug.at.gmane@xs4all.nl> writes:

> Today, Kim F. Storm <storm@cua.dk> wrote:
> 
> > huug <huug.at.gmane@xs4all.nl> writes:
> > 
> >> > BTW, it is still on my to-do list to make the fringe glyphs user
> >> > customizable...
> >> 
> >> And its position too, I hope. 
> > 
> > Yes, I'm working on placing the fringe between the display margin
> > and the text area.
> > 
> >>                               Even if it was just a
> >>                               follow-scrollbar..
> > 
> > I don't understand.  What are you suggesting?
> 
> I want the glyphs in the right fringe, by the scrollbar. Less
> detraction in the center of vision..

Such a proposal was discussed more than a year ago:

If indicate-empty-lines was set to 'right, the empty line glyph would
be displayed in the right fringe.  IIRC, it was decided that it was an
unnecessary customization, but I don't recall who made that decision.

It would be trivial to add this, so what do others think about it?

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

Re: Gtk scrollbar: thumb too short

[Jan D.]

fredagen den 28 mars 2003 kl 23.35 skrev Robert J. Chassell:

> Konqueror fails, too.
>
>        I don't claim that one view is better than the other ...
>
>     I just tried to move the bottom line of an article shown in the
>     Mozilla web browser up so I could see it better, and I could not.
>
> I just tried the same on Konqueror using KDE.  Equivalent failure.
>
> It looks to me that `mainstream' browsers are as lacking of decent
> interface design as mainstream desktops that lack `incremental search'
> (which Jef Raskin (of Apple Macintosh interface fame) recommends in
> his book, `The Humane Interface').

Mozilla actually has incremental search.  Type / and off you go (may
require mozilla 1.3).

	Jan D.

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    Bug or feature?  I do not know whether there is a "correct" answer to
    that question.  It depends on what the user is trying to do and on the
    user's taste and expectations.

I think we should consider it a feature.  Consider outline mode, for
instance.  I think it is correct that the scroll bar indicates the
amount of total text in the area displayed, including the hidden parts
of the outline.

    In other words, what the thumb seems to measure is the proportion of
    total (visible or invisible) text between top and bottom of the screen
    compared to the total text in the buffer. 

    This seems to be the behavior in Emacs 20.7 with native scrollbars, as
    well as in the current 21.3.50 CVS, both with native 
    (./configure --without-toolkit-scroll-bars) and with Xaw3d (no options
    to configure) scroll bars.

That is the way it should work.

      Basically, the scrollbar should be based on
    "number of vertical pixels" rather than "number of chars", but
    given the current way Emacs is written, it's basically impossible
    to do.

Basing it on pixels would be consistent behavior, but (as you said) it
isn't feasible.  For Emacs to do this computation for the whole
of a long buffer would take much too long.

    3) Updating thumb size while dragging
       That just seems irritating.  If a user selcts the bottom of a
       large thumb at the start of the drag then the thumb shrinks they
       end up in an odd position.

This seems to be a case where all alternatives are flawed.  I agree
that changing the thumb size while dragging would look strange--but if
you don't change the thumb size while dragging, it has to change when
you stop dragging, and that would look strange.

I don't yet have an opinion about which one is better.

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    > I prefer the Emacs 20.7 way of doing it; that way, I don't think of
    > the thumb as telling me that the buffer is larger than it really is.

    It's also the 21.3 behavior, except in Motif.

You posted a patch recently--was that intended to obtain this
behavior with Motif as well?

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

>     > I prefer the Emacs 20.7 way of doing it; that way, I don't think of
>     > the thumb as telling me that the buffer is larger than it really is.
> 
>     It's also the 21.3 behavior, except in Motif.
> 
> You posted a patch recently--was that intended to obtain this
> behavior with Motif as well?

Yes, the patch causes Motif to use the same thumb positio&size as
is used by Xaw3d and the native scrollbar.  The only snag is that
the thumb is temporarily forced to zero-length while dragging.
It looks a bit unclean but featurewise, it's pretty much "perfect"
and the implementation is very simple with no ugly hack as
we currently have for Xaw3d.


	Stefan

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    An observation I'd make is that a scrollbar really encodes two
    things:

     - A value
     - A percentage of a total size

    If we look at the scrollbar on the screen, we have:

     v = thumb_start / (trough_pixels - thumb_pixels)
     p = thumb_pixels / trough_pixels

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 GTK+ case these two quantities are related to the
    document size.

     v = start_of_visible / MAX (size_of_visible, size_of_document) - size_of_visible

thumb_start / trough_pixels normally corresponds to
start_of_visible / MAX (size_of_visible, size_of_document)

If this relationship continues to apply when Emacs overscrolls,
you get the behavior I have asked for.


I think of the scroll bar as showing how the document is divided into
three parts: the part above the screen, the part on the screen, and
the part below the screen.  The sizes of the three parts of the scroll
bar are in proportion to those three parts of the document.

When Emacs overscrolls, the last part of the document has negative
size.  Properly speaking, the thumb should extend beyond the end of
the trough.  Alas, that is impossible.  The Emacs 20.7 behavior is the
closest possible approximation.

Re: Gtk scrollbar: thumb too short

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> > [The fringe glyph for this is rather ugly though; it should really be
> > something a bit less visually prominent...]
>
> Are you talking about the 21.2 fringe glyph (a block) or the new glyph
> in CVS head (small dashes) ?

The `small dashes' glyph.

> What kind of glyph do you suggest?

Just something a bit less visually dominant -- the dashes seem better
than the blocks, but because there are very many densely spaced dashes,
they still are quite distracting.

Here's the current glyph (this ASCII drawing exaggerates the vertical
dimension, so in reality it looks a bit more dense vertically):


      | 4  |
              _
       ####   _1
               2
              _
       ####   _1
               2
              _
       ####   _1
               2
              _
       ####   _1
               2
              _
       ####   _1
               2
              _
       ####   _1


How about something like this instead:


      | 4  |
              _
       ##     _1

               4

              _
         ##   _1

               4

              _
       ##     _1

               4

              _
         ##   _1


?

[Note that I use a white foreground on a dark background, which might
influence this somewhat]

-Miles
--
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: Gtk scrollbar: thumb too short

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> storm@cua.dk (Kim F. Storm) writes:
> > > [The fringe glyph for this is rather ugly though; it should really be
> > > something a bit less visually prominent...]
> >
> > Are you talking about the 21.2 fringe glyph (a block) or the new glyph
> > in CVS head (small dashes) ?
> 
> The `small dashes' glyph.
> 
> > What kind of glyph do you suggest?
> 
> Just something a bit less visually dominant -- the dashes seem better
> than the blocks, but because there are very many densely spaced dashes,
> they still are quite distracting.

Personally, I don't think I will find your suggestion less distracting,
and I don't think it will be easy to find something which will please
everyone.  

I would guess that people will fall into three categories:

- those who WANT the empty line glyph to be very VISIBLE,
- those who want it to be BARELY visible.
- those who don't want the glyph at all (the default behaviour).

I think it will be impossible to find a glyph which pleases both the
first and second group...

> 
> [Note that I use a white foreground on a dark background, which might
> influence this somewhat]

I still think it will be be best option to make the fringe glyphs
configurable...

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

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Sun, 2003-03-30 at 14:24, Richard Stallman wrote:
>     An observation I'd make is that a scrollbar really encodes two
>     things:
> 
>      - A value
>      - A percentage of a total size
> 
>     If we look at the scrollbar on the screen, we have:
> 
>      v = thumb_start / (trough_pixels - thumb_pixels)
>      p = thumb_pixels / trough_pixels
> 
> 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.

But in more complicated cases, your approach isn't possible. The
normal situation where this comes up in GTK+ is when the thumb
is clamped to its minimum size. 

>     For the normal GTK+ case these two quantities are related to the
>     document size.
> 
>      v = start_of_visible / MAX (size_of_visible, size_of_document) - size_of_visible
> 
> thumb_start / trough_pixels normally corresponds to
> start_of_visible / MAX (size_of_visible, size_of_document)
> 
> If this relationship continues to apply when Emacs overscrolls,
> you get the behavior I have asked for.

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. As discussed earlier,
   this will cause drawing problems, and also may cause
   problems for the ability of the user to click and drag
   on the thumb.

   The scrollbar models a physical system where there is a
   knob slid along a trough. If in the physical system 
   (a stereo component say), the knob popped out of the trough
   on the physical system, it would be a sign of shoddy 
   workmanship. I think the same holds for the onscreen case.

 - 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.

> I think of the scroll bar as showing how the document is divided into
> three parts: the part above the screen, the part on the screen, and
> the part below the screen.  The sizes of the three parts of the scroll
> bar are in proportion to those three parts of the document.
> 
> When Emacs overscrolls, the last part of the document has negative
> size.  Properly speaking, the thumb should extend beyond the end of
> the trough.  Alas, that is impossible.  The Emacs 20.7 behavior is the
> closest possible approximation.

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. While you may think of the scrollbar as
a miniature view of the document, it is also presented
to the user as a physical control, with obvious limits as
to how far the scrollbar can be dragged.

You have to decide whether dragging the scrollbar to the bottom:

 - Scrolls to last page of the document
 - Scrolls to the maximally overscrolled position (one line
   at the top of the screeen)

(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
than something where the user can just drag the scrollbar down
as far as it can go quickly.)

Regards,
                                           Owen

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Owen Taylor wrote:

   (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
   than something where the user can just drag the scrollbar down
   as far as it can go quickly.)

I agree that it might be problematic to make overscrolling the default
behavior for *all* applications.  The problem you describe would be
particularly bad for applications that have standard clickable lines at
the bottom that the user may want to reach quickly, style:

<<< Previous       Home       Next>>>

or whatever, especially if that application provided no other
convenient way to scroll to that place (say pressing the "End" key.)

For the character based philosophy of Emacs it is clear where the
overscrolled region starts (just after the last character), but what
exactly happens for applications that themselves already leave
whitespace at the bottom to ensure that the last relevant line will
not be positioned too far to the bottom?

   You have to decide whether dragging the scrollbar to the bottom:

    - Scrolls to last page of the document
    - Scrolls to the maximally overscrolled position (one line
      at the top of the screeen)

Would it be possible for GTK to leave that choice either up to the
application or up to the user?  There are plenty of applications were
if it were up to me I would choose possibility (1).  For Emacs I
would choose (2), the current behavior.  Actually, for Emacs I
personally use the native scrollbar, which seems better adapted to
Emacs' character based philosophy.  This does not mean that I would
want to use that scrollbar for other applications.  What is a good
scrollbar for Emacs is not necessarily a good scrollbar for other
applications and vice versa.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Mon, 2003-03-31 at 17:06, Luc Teirlinck wrote:

>    You have to decide whether dragging the scrollbar to the bottom:
> 
>     - Scrolls to last page of the document
>     - Scrolls to the maximally overscrolled position (one line
>       at the top of the screeen)
> 
> Would it be possible for GTK to leave that choice either up to the
> application or up to the user?  There are plenty of applications were
> if it were up to me I would choose possibility (1).  For Emacs I
> would choose (2), the current behavior.  Actually, for Emacs I
> personally use the native scrollbar, which seems better adapted to
> Emacs' character based philosophy.  This does not mean that I would
> want to use that scrollbar for other applications.  What is a good
> scrollbar for Emacs is not necessarily a good scrollbar for other
> applications and vice versa.

GTK+ apps can already do both - I described how to implement the
second in some detail in a recent mail.

What I'm opposed to is having dragging the scrollbar to the bottom
scroll to the last page of the document, then dragging it _past_
the bottom overscroll the buffer. I don't think dragging past
the end is a meaningful feature to have for this widget.

Regards,
                                     Owen

Re: Gtk scrollbar: thumb too short

[Robert J. Chassell]

      The scrollbar models a physical system where there is a
      knob slid along a trough. If in the physical system 
      (a stereo component say), the knob popped out of the trough
      on the physical system, it would be a sign of shoddy 
      workmanship. I think the same holds for the onscreen case.

Ah ... This is the fundamental misconception.  Yes, in a physical
system, you would complain if the knob `popped out of the trough' or
slid under the end of it.

But displays in a computer are not restricted to strictly physical
contstraints.  In particular, in GNU Emacs, the scroll bar should show

    ... how the document is divided into three parts: the part above
    the screen, the part on the screen, and the part below the screen.

It is both false and misleading to pretend that a thumb in an Emacs
scroll bar is like a knob on a 1948 Zenith radio.  The `thumb' is
derived from the physical knob, but it is not the same; it is an
improvement, just as GNU Emacs itself is an improvement over the
mechanical typewriter on which I first learned to type.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Owen Taylor wrote:

   GTK+ apps can already do both - I described how to implement the
   second in some detail in a recent mail.

   What I'm opposed to is having dragging the scrollbar to the bottom
   scroll to the last page of the document, then dragging it _past_
   the bottom overscroll the buffer. I don't think dragging past
   the end is a meaningful feature to have for this widget.

Am I misunderstanding something?  This is the behavior of the native
scrollbar:

C-x b : new buffer, no scrolling possible.

type `a' : still no scrolling possible.

type NEWLINE `b' : now I can scroll to bring `b' to the top but no
further.  Does anybody want to scroll further than that?  The native
scrollbar can presently not do that.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Owen Taylor wrote:

   What I'm opposed to is having dragging the scrollbar to the bottom
   scroll to the last page of the document, then dragging it _past_
   the bottom overscroll the buffer. I don't think dragging past
   the end is a meaningful feature to have for this widget.

I believe I misunderstood you in my earlier reply.  I believe I
understand it now: you are opposed to the thumb hitting the bottom
while actual scrolling is still possible.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Owen Taylor wrote:

   While you may think of the scrollbar as a miniature view of the
   document, it is also presented to the user as a physical control,
   with obvious limits as to how far the scrollbar can be dragged.

I believe that this all boils down to the difference between (1) a
character and (2) a pixel based philosophy.  For efficiency reasons,
Emacs has no choice but to adopt (1).  Given that, it should do it
consistently, otherwise things would become unpredictable.

For (1) the thumb indicates the percentage of total "content"
contained in the part of the buffer that is represented above, on and
below the screen.  I believe that for (2) the thumb indicates how much
more upward and downward scrolling is possible, regardless of how much
extra content that is going to bring into view.

Start with an empty buffer in a window that has room for 60 lines of
regular character size and type:

a NEWLINE b

I believe that according to (1) the thumb should still cover the
entire length of the scrollbar, but according to (2), it should only
cover the top 60/61 of the scrollbar.  That is because there is now
one extra screen line we can scroll down to and according to the
visually based philosophy of (2), that matters.  According to the
character based philosophy of (1), there are no extra characters that
can be brought into view, even though extra scrolling is possible.

Now scroll the second line to the top.  One screen line, two
characters, scrolled of the screen.  We still have one third of the
characters on the screen, so for (1), the thumb should occupy the
bottom one third.  This is exactly what happens for the native
scrollbar.  (I do not see why the knob should "pop out of the trough".
The overscrolled piece contains no characters, so according to (1) its
size is 0, it does not really "exist", it is an optical illusion.)
For (2), I believe the thumb should occupy the bottom 60/61 of the
scrollbar.  Actually, I believe that for (2) mere scrolling should not
change the size of the thumb.

I believe that it is correct for the default behavior of GTK to be
pixel based, since it is more "intuitive" and covers the needs of more
applications.  I believe that the question is whether somehow one
could increase the "customizability" of the GTK scrollbar, to make it
possible, to have it, within Emacs, better approximate the native
scrollbar, without negatively affecting its interaction with
applications that want a pixel based behavior.  Alternatively, people
who prefer the consistently character based behavior (compared, not
with a consistently pixel based philosophy, but with some inconsistent
and unpredictable mixture) could use the native scrollbar (as I do).

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    > 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.

    But in more complicated cases, your approach isn't possible. 

Of course it is possible.  Emacs already does it, with some toolkits.

    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.

     - 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"?)

    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.

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

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

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Mon, 2003-03-31 at 19:28, Luc Teirlinck wrote:
> Owen Taylor wrote:
> 
>    While you may think of the scrollbar as a miniature view of the
>    document, it is also presented to the user as a physical control,
>    with obvious limits as to how far the scrollbar can be dragged.
> 
> I believe that this all boils down to the difference between (1) a
> character and (2) a pixel based philosophy.  For efficiency reasons,
> Emacs has no choice but to adopt (1).  Given that, it should do it
> consistently, otherwise things would become unpredictable.
>
> For (1) the thumb indicates the percentage of total "content"
> contained in the part of the buffer that is represented above, on and
> below the screen.  I believe that for (2) the thumb indicates how much
> more upward and downward scrolling is possible, regardless of how much
> extra content that is going to bring into view.
> 
> Start with an empty buffer in a window that has room for 60 lines of
> regular character size and type:
> 
> a NEWLINE b
> 
> I believe that according to (1) the thumb should still cover the
> entire length of the scrollbar, but according to (2), it should only
> cover the top 60/61 of the scrollbar.  That is because there is now
> one extra screen line we can scroll down to and according to the
> visually based philosophy of (2), that matters.  According to the
> character based philosophy of (1), there are no extra characters that
> can be brought into view, even though extra scrolling is possible.
>
> Now scroll the second line to the top.  One screen line, two
> characters, scrolled of the screen.  We still have one third of the
> characters on the screen, so for (1), the thumb should occupy the
> bottom one third.  This is exactly what happens for the native
> scrollbar.  (I do not see why the knob should "pop out of the trough".
> The overscrolled piece contains no characters, so according to (1) its
> size is 0, it does not really "exist", it is an optical illusion.)
> For (2), I believe the thumb should occupy the bottom 60/61 of the
> scrollbar.  Actually, I believe that for (2) mere scrolling should not
> change the size of the thumb.
> 
> I believe that it is correct for the default behavior of GTK to be
> pixel based, since it is more "intuitive" and covers the needs of more
> applications.  I believe that the question is whether somehow one
> could increase the "customizability" of the GTK scrollbar, to make it
> possible, to have it, within Emacs, better approximate the native
> scrollbar, without negatively affecting its interaction with
> applications that want a pixel based behavior.  Alternatively, people
> who prefer the consistently character based behavior (compared, not
> with a consistently pixel based philosophy, but with some inconsistent
> and unpredictable mixture) could use the native scrollbar (as I do).

While with your character based philosophy, you've described a perfectly
consistent visual model, I don't think it corresponds to workable
control for manipulation with the mouse.

This is most obvious in the case where you run into the minimum
scrollbar size. In the theme I'm using, the minimum scrollbar
size is 30 pixels.

So, all scroll positions that involve the first line being within
3% (30/1000) of the end of the buffer map into the exact same thumb
appearance. Overscrolling a buffer of more than a few thousand
lines with the mouse would not be possible.

But I'd say that you basically have the same problem even for
small buffers. If the scrollbar occupies the entire scrollbar
trough, dragging it downward doesn't correspond to any physical
motion of a scrollbar thumb. If you want that mouse action
to be possible, I'd argue that you really shouldn't use a control
that looks like it has real physical presence - something like 
the Emacs native scrollbar is more correct.

Regards,
                                                Owen

Re: Gtk scrollbar: thumb too short

[Kai Großjohann]

I confess that I am amazed at the length of the discussion that
ensued from my original posting.  Dozens of postings from very smart
people.

Yet it seems that we all have overlooked something obvious.  It is
very easy to solve the problem.

Vs gur guhzo vf gbb fubeg, ubj nobhg gelvat gur vaqrk svatre?
-- 
A preposition is not a good thing to end a sentence with.

Re: Gtk scrollbar: thumb too short

[Miles Bader]

Owen Taylor <otaylor@redhat.com> writes:
> 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.

What are you suggesting?  A knob?  The scrollbar fits quite well, even
if emacs users don't use it in exactly the same way as with other apps.

In my personal use, I rarely drag -- but I _do_ sometimes, because
occasionally it's the best way to quickly scan through a file.  From
what I've observed, novice users drag more often.

> 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.

The above two behaviors are merely _extensions_ to the `usual' behavior
(as you define it), and fairly natural ones at that -- they extrapolate
your `model' beyond the (arbitrary) boundaries you've set for other
apps, but only in boundary cases, and only a little bit.

I somehow get the impression you're worried that if GTK supports these
extensions for emacs, it will `pollute' users' idea of how a scrollbar
works; if so this seems kind of silly.

Emacs should _definitely_ use the same scrollbar as other GTK apps
because regardless of any different behavior in corner cases, it's 95%
the same thing.  Users know that when they want to scroll, they can use
a scrollbar, and the emacs extensions being discussed make absolutely
no fundamental changes in the way scrollbars work.

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: Gtk scrollbar: thumb too short

[Miles Bader]

Owen Taylor <otaylor@redhat.com> writes:
> If the scrollbar occupies the entire scrollbar trough, dragging it
> downward doesn't correspond to any physical motion of a scrollbar
> thumb. If you want that mouse action to be possible, I'd argue that
> you really shouldn't use a control that looks like it has real
> physical presence - something like the Emacs native scrollbar is more
> correct.

That might be an argument if the desired emacs behavior was somehow
totally bizarre -- but it's not, it merely pushes the boundaries a bit
beyond what other GTK apps do.  There are various ways to think of the
suggested behavior (such as pushing the bar into a hole in the end or
something), but the basic point is that it _feels_ natural and
`plausible'; it doesn't break the illusion of manipulating a physical
thing, as you claim.

-Miles
-- 
Quidquid latine dictum sit, altum viditur.

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Owen Taylor wrote:

   This is most obvious in the case where you run into the minimum
   scrollbar size. In the theme I'm using, the minimum scrollbar
   size is 30 pixels.

Do you really mean scrollbar size (window height essentially)  or
thumb size?

   So, all scroll positions that involve the first line being within
   3% (30/1000) of the end of the buffer map into the exact same thumb
   appearance. Overscrolling a buffer of more than a few thousand
   lines with the mouse would not be possible.

With the native scrollbar, I was able to scroll the last line of the
NEWS buffer (11298 lines) to the top.  I first positioned the last
line of the buffer at the bottom of the screen (thumb size ten pixels)
and then overscrolled to put that line at the top (thumb size four
pixels).  Of course, the native scrollbar has no 30 pixel size limit.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Miles Bader wrote:

   Emacs should _definitely_ use the same scrollbar as other GTK apps
   because regardless of any different behavior in corner cases, it's 95%
   the same thing.

I am not so sure.  I personally believe that the difference between a
character based view and a pixel based view is more than 5%.  I
believe there are essentially three possibilities:

1.  Restore the native scrollbar as the default.  (Perfectly
    acceptable to me, in fact, it is the solution I have chosen for my
    personal use, but I do not know whether it would be acceptable to
    other people.)

2.  Use an imperfect approximation of the GTK scrollbar (or some other
    scrollbar) that looks like the GTK scrollbar, but that is a not
    very consistent hybrid between the GTK scrollbar and the native one.

3.  Make the GTK scrollbar more customizable so that it can optionally
    handle a character based approach and hence behave, within Emacs,
    more like the native scrollbar than the pixel based variant of the
    GTK scrollbar.

Both 1. and 3. would satisfy me as an Emacs user.  If 2. is chosen
then I hope that one will keep allowing users like me to override the
default choice using: ./configure --without-toolkit-scroll-bars

   I somehow get the impression you're worried that if GTK supports these
   extensions for emacs, it will `pollute' users' idea of how a scrollbar
   works; if so this seems kind of silly.

Owen should clarify his concerns himself, but I have the impression
that his concerns with solution 3. (and 2., I guess) are that users
would not longer clearly know what to expect when they see a GTK
scrollbar.  The appearance of the GTK scrollbar was chosen to provide
a metaphor for a a pixel based approach.  Exact same appearance with
different behavior is confusing, unless the difference was due to
customizations deliberately made by the user (as opposed to by the
application).

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
>    Emacs should _definitely_ use the same scrollbar as other GTK apps
>    because regardless of any different behavior in corner cases, it's 95%
>    the same thing.
> 
> I am not so sure.  I personally believe that the difference between a
> character based view and a pixel based view is more than 5%.  I
> believe there are essentially three possibilities:

I use both, and even though I'm (very) occasionally surprised, they feel
pretty much the same to me.  I think my claim is that users don't really
worry about the details so much, as long as things basically `feel'
right, and that the differences being discussed simply aren't the sort
that will cause real problems.

> 3.  Make the GTK scrollbar more customizable so that it can optionally
>     handle a character based approach and hence behave, within Emacs,
>     more like the native scrollbar than the pixel based variant of the
>     GTK scrollbar.

I think this is the only reasonable solution.

(1) is no good because, I _want_ an emacs scrollbar that looks like my
other GTK scrollbars, follows my GTK theme, etc.  I think many other
users feel the same way.

(2) seems like a non-starter, because by looking the same, it would end
up causing exactly the same problems that (3) would (to the extent that
there are such problemsd), only it would be worse, because such
`lookalike' implemenations are inevitably imperfect.

> Owen should clarify his concerns himself, but I have the impression
> that his concerns with solution 3. (and 2., I guess) are that users
> would not longer clearly know what to expect when they see a GTK
> scrollbar.  The appearance of the GTK scrollbar was chosen to provide
> a metaphor for a a pixel based approach.  Exact same appearance with
> different behavior is confusing, unless the difference was due to
> customizations deliberately made by the user (as opposed to by the
> application).

I think that if this is the worry, it's groundless, because the emacs
extensions are just that -- extensions, which extrapolate existing
behavior, not really arbitrary differences in details, which is the
usual case of problems arising with lookalike implemenations.

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Miles Bader wrote:

   I think that if this is the worry, it's groundless, because the emacs
   extensions are just that -- extensions, which extrapolate existing
   behavior, not really arbitrary differences in details, which is the
   usual case of problems arising with lookalike implemenations.

It is a little bit more complicated than that.  The Emacs behavior
would be an alternative behavior, not an extension.  There are two
unrelated issues:

1. overscrolling versus non-overscrolling.  As Owen pointed out to me,
   GTK already supports both.  That is not the issue we are
   discussing.

2. A character based approach versus a pixel based approach.

Two applications, Emacs and PixelStuff start out with exactly one
window height (say sixty lines) full of stuff.  Both allow
overscrolling to put the last line at the top.  In Emacs, the thumb
covers the entire length of the scrollbar, because all text is
visible, in PixelStuff it covers approximately half (60/119) of the
scrollbar.  We scroll to the bottom.  In PixelStuff, the thumb stays
the same size and moves smoothly to the bottom, until it hits the
bottom, exactly when the last line of real text gets at the top.  In
Emacs, the thumb shrinks gradually to a size determined by (amount of
characters on the last line) / (total amount of characters).  This is
different behavior, not an extension of behavior.

A user of PixelStuff using Emacs for the first time will conclude that
Emacs does not allow overscrolling, because the thumb already is at
the bottom, so no downward scrolling is possible.  An Emacs user using
PixelStuff for the first time will conclude that he is only looking
at half of the real text.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
>    I think that if this is the worry, it's groundless, because the emacs
>    extensions are just that -- extensions, which extrapolate existing
>    behavior, not really arbitrary differences in details, which is the
>    usual case of problems arising with lookalike implemenations.
> 
> It is a little bit more complicated than that.  The Emacs behavior
> would be an alternative behavior, not an extension.

My claim is that in practice, this doesn't matter, because they're
`close enough.'  Users will gain far more from exploiting the similarity
in behavior than they'll lose by being confused over the differences.

That, and my desire for a consistent look (which I think is very common)
between applications, are why I say that emacs should definitely use GTK
scrollbars, not something gratuitously funky-looking just to make the
point that there's a difference.

I suppose emacs could use a GTK scrollbar with the text `THIS IS NOT A
GTK SCROLLBAR' emblazoned in the trough... :-)

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    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.

The thumb size is quantized because the display is made of pixels.
Whatever model we use for the scroll bar will be distorted a little by
quantization.  This doesn't really affect any of the arguments.

    In fact, your doesn't work at all unless there is a difference between:

     - The minimum size the scrollbar thumb can under normal circumstances

This minimum is irrelevant except for very large files.  For instance,
etc/NEWS is almost half a meg, and yet its thumb is several pixels
high.  A file would have to be several meg before its thumb would have
the minimum possible height.

However, quantization does cause problems.  You cannot use mouse-2 to
scroll were you will.  In fact, a single pixel motion of the thumb in
etc/NEWS corresponds to more than one screenful.  If you scroll
through the file using mouse-2, there are parts you will not even see.
That is true regardless of how the scroll bar handles overscrolling.
However, it does have a relationship with the issue of overscrolling.

I compiled with some sort of athena widgets, and the behavior I get
for overscrolling is the one that you want.  If I slide the thumb all
the way to the bottom, my screen is blank.  But if I carefully
position the thumb one pixel up from the bottom, the last line is off
the bottom of the screen.  There is no place to put the thumb which
makes the end of the text visible.

With the behavior I am recommending, sliding the thumb to the bottom
would reliably make the last screenful of text visible.

    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.

Actually I wasn't thinking about that question.  I don't know what GTK
scrollbars look like, so I did not know they have beveling.  Now that
you mention it, I think it would be desirable to omit the bottom
beveling, to indicate that the thumb virtually extends beyond the end
of the trough.

However, I am not saying that it should actually draw the thumb in the
space beyond the end of the trough.  I am saying that if it happens to
do that, it is ok.

    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.

When an application's internal concepts don't fit that model,
trying to force it to fit does not help.

Re: Gtk scrollbar: thumb too short

[Kai Großjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Two applications, Emacs and PixelStuff start out with exactly one
> window height (say sixty lines) full of stuff.  Both allow
> overscrolling to put the last line at the top.  In Emacs, the thumb
> covers the entire length of the scrollbar, because all text is
> visible, in PixelStuff it covers approximately half (60/119) of the
> scrollbar.  We scroll to the bottom.  In PixelStuff, the thumb stays
> the same size and moves smoothly to the bottom, until it hits the
> bottom, exactly when the last line of real text gets at the top.  In
> Emacs, the thumb shrinks gradually to a size determined by (amount of
> characters on the last line) / (total amount of characters).  This is
> different behavior, not an extension of behavior.

I agree that this would be confusing, but until now I thought that
Emacs was the only (Gtk) program which exhibited PixelStuff behavior.

So I thought the issue was whether to change the only application
that exhibits deviating behavior to exhibit another deviating
behavior.

But the thread is so long, I might have missed or forgotten some
things.
-- 
A preposition is not a good thing to end a sentence with.

Re: Gtk scrollbar: thumb too short

[Robert J. Chassell]

It is better to modify `PixelStuff' to behave like GNU Emacs
version 20.7. 

Luc Teirlinck <teirllm@dms.auburn.edu> describes the 
`PixelStuff' variation of Emacs like this:

    A user of PixelStuff using Emacs for the first time will conclude
    that Emacs does not allow overscrolling, because the thumb already
    is at the bottom, so no downward scrolling is possible.

Correct, however, the user can experiment with the Emacs thumb and
find that he can over scroll.  So only a little learning is required.

    An Emacs user using PixelStuff for the first time will conclude
    that he is only looking at half of the real text.

Yes, that is exactly my experience using the GTK toolkit.

Unfortunately, with experiment, I found that I could never cause the
`PixelStuff' variation of Emacs to show only the full amount of text
and no more.

The `PixelStuff' thumb kept claiming the buffer contained more text
than it did.

Incidentally, while writing this line, I brought it to the center of
my window by typing a `C-l' (recenter) command.  The command is `in my
fingers' -- I did not realize I was `moving the text up' to make my
work easier until after I had done it.  

As a consequence, I am overscrolling this buffer.  I am glad
overscrolling is possible; I really dislike Galeon for forcing me to
move my eyes to the bottom of the screen to read Web pages whose text
cannot be `moved up'.

And I am glad that the thumb tells me correctly what portion of the
text is in the window.  Mostly, I use it as a non-intrusive sensor,
telling me where I am in the text and how long it it.  Occasionally, I
will scroll with the mouse on the thumb.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk scrollbar: thumb too short

[Kai Großjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kai GrossJohann wrote:
>
>    I agree that this would be confusing, but until now I thought that
>    Emacs was the only (Gtk) program which exhibited PixelStuff behavior.
>
> I indeed have trouble finding other applications that allow
> overscrolling.  But it is clear that there are people who wish that
> there were more applications that would.  

OK.

> If an application with a pixel based philosophy decides to allow
> overscrolling, it is likely that it would want the scrollbar to
> behave in the way I described PixelStuff's scrollbar.

Really?  I never thought that one follows from the other.  For me,
the no-toolkit Emacs scrollbar behavior near end of buffer appears
very intuitive, and I never made a direct connection between this
behavior and the fact that the thumb changes size from time to time
even in the middle of the buffer.

I also observed thumb shrinking in *shell* buffers (when there is a
shell command producing lots of output), and I subconsciously lumped
this together with the thumb shrinking when overscrolling.

For me, the idea that (thumb size / total scrollbar size) is equal to
(visible amount of content / total buffer size) is very intuitive.
You can observe it in many situations.  It doesn't (directly) have
anything to do with the question of how to measure size.

-- 
A preposition is not a good thing to end a sentence with.

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Kai GrossJohann wrote:

   I agree that this would be confusing, but until now I thought that
   Emacs was the only (Gtk) program which exhibited PixelStuff behavior.

I indeed have trouble finding other applications that allow
overscrolling.  But it is clear that there are people who wish that
there were more applications that would.  If an application with a
pixel based philosophy decides to allow overscrolling, it is likely
that it would want the scrollbar to behave in the way I described
PixelStuff's scrollbar.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Kai Großjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kai GrossJohann wrote:
>
>    It doesn't (directly) have anything to do with the question of how
>    to measure size.
>
> Yes it does, because the overscrolled piece contains no content
> (characters) but it covers a visible amount of window height (pixels).
> Visually, the overscrolled piece is a piece of the "document" that you
> can scroll to.

Okay, now I understand.

Personally, I like the thumb size to represent visible content size.
-- 
A preposition is not a good thing to end a sentence with.

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

> Two applications, Emacs and PixelStuff start out with exactly one
> window height (say sixty lines) full of stuff.  Both allow
> overscrolling to put the last line at the top.  In Emacs, the thumb
> covers the entire length of the scrollbar, because all text is
> visible, in PixelStuff it covers approximately half (60/119) of the
> scrollbar.

I.e. the PixelStuff behavior is the Emacs/Motif behavior.
I've been using it for a while and I must say even though one
gets used to it, I don't like it.  The problem is that the visual
appearance of the scrollbar doesn't tell you clearly when point-max
is visible so I still often end up trying to scroll down
(especially in Gnus for some reason) and feel silly when I discover
that there's nothing more to scroll.

I've now switched to the new behavior I suggest (i.e. revert
to the native scrollbar behavior) but work around the problematic
interaction with Motif's scrollbar (the same problem as with Xaw3d
and GTK) by setting the thumb size to 0 while dragging it: it's
not perfect, but I find it much more useful.


	Stefan

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Kai GrossJohann wrote:

   For me, the idea that (thumb size / total scrollbar size) is equal to
   (visible amount of content / total buffer size) is very intuitive.

To me too.  But apparently not to everybody.  I do not have the
impression that Owen considers this to be intuitive.  The emphasis is
on "content" versus occupied window height.

   It doesn't (directly) have anything to do with the question of how
   to measure size.

Yes it does, because the overscrolled piece contains no content
(characters) but it covers a visible amount of window height (pixels).
Visually, the overscrolled piece is a piece of the "document" that you
can scroll to.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> I've now switched to the new behavior I suggest (i.e. revert to the
> native scrollbar behavior) but work around the problematic interaction
> with Motif's scrollbar (the same problem as with Xaw3d and GTK) by
> setting the thumb size to 0 while dragging it: it's not perfect, but I
> find it much more useful.

So the scrollbar shrinks to a small rectangle while being dragged
(and so if you grab the _end_, you end up dragging it from a distance)?

This seems rather drastic considering that _most_ of the time there
really isn't any problem, but you're making the common case ugly to
cover the rare glitches that do happen.

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

      The appearance of the GTK scrollbar was chosen to provide
    a metaphor for a a pixel based approach.  Exact same appearance with
    different behavior is confusing, 

The same appearance with gratuitous incompatible behavior would be
confusing, but handling overscrolling is an extension, not an
incompatibility.  No matter how the GTK scroll bar handles
overscrolling, this will be an extension to the usual scroll bar
behavior.  It cannot be 100% compatible, but it can be more compatible
or less compatible.

Handling overscrolling the native scroll bar way, by virtually moving
the thumb "out of" the trough, is mostly compatible with the normal
behavior, because it results in the same visual appearance for the
scroll bar for all the non-overscrolled cases.  If you don't
overscroll, everything looks normal.

Handling overscrolling in the current Motif way, by treating the
maximally overscrolled position as "the end", is incompatible in user
terms, because the same scroll position in the buffer corresponds to
a different appearance of the scroll bar.

    I indeed have trouble finding other applications that allow
    overscrolling.  But it is clear that there are people who wish that
    there were more applications that would.  If an application with a
    pixel based philosophy decides to allow overscrolling, it is likely
    that it would want the scrollbar to behave in the way I described
    PixelStuff's scrollbar.

If an app with pixel-based scrolling supports overscrolling, I think
it should display the overscrolling just as Emacs should, by having
the thumb virtually move beyond the end of the trough.

    Visually, the overscrolled piece is a piece of the "document" that you
    can scroll to.

Even for pixel-based apps, I don't think this is a good way to look
at the issue.

    > 3.  Make the GTK scrollbar more customizable so that it can optionally
    >     handle a character based approach and hence behave, within Emacs,
    >     more like the native scrollbar than the pixel based variant of the
    >     GTK scrollbar.

    I think this is the only reasonable solution.

I agree with Miles--this is the only right way.

Owen, would you please implement this facility in the GTK scroll bar?

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

> > I've now switched to the new behavior I suggest (i.e. revert to the
> > native scrollbar behavior) but work around the problematic interaction
> > with Motif's scrollbar (the same problem as with Xaw3d and GTK) by
> > setting the thumb size to 0 while dragging it: it's not perfect, but I
> > find it much more useful.
> 
> So the scrollbar shrinks to a small rectangle while being dragged
> (and so if you grab the _end_, you end up dragging it from a distance)?

With Xaw3d, the small thumb actually moves to meet the mouse.
(well, it's more complex than that because the first move (when
you middle-click) takes place before the thumb is resized,
so it might not meet the mouse, but once you move the mouse
then it finally really moves to meet the mouse).

> This seems rather drastic considering that _most_ of the time there
> really isn't any problem, but you're making the common case ugly to
> cover the rare glitches that do happen.

Agreed.  Which is why I haven't installed it.
OTOH, the "rare glitches" are really annoying and difficult to work
around, so I actually prefer this behavior (while still waiting to see
Xaw3d fixed to behave like Xaw (which is the same behavior as the
native scrollbar)).


	Stefan

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Thu, 2003-04-03 at 05:38, Richard Stallman wrote:

>     > 3.  Make the GTK scrollbar more customizable so that it can optionally
>     >     handle a character based approach and hence behave, within Emacs,
>     >     more like the native scrollbar than the pixel based variant of the
>     >     GTK scrollbar.
> 
>     I think this is the only reasonable solution.
> 
> I agree with Miles--this is the only right way.
> 
> Owen, would you please implement this facility in the GTK scroll bar?

I don't think there has been a satisfactory explanation of how you
are going to deal with minimum size issues; which for some themes
occur on quite moderately sized buffers. (As I said earlier, for
Red Hat's default theme, the minimum scrollbar thumb size is
~30 pixels)

I also am not convinced that the behavior is right from the point of
view of a user; the ends of the scrollbar should be the ends
of the scrollbar.

However, I was reminded this morning that a facility that allows
you to implement your desired behavior was actually added prior
to GTK+-2.2.

If you connect to the "adjust_bounds" signal on GtkRange (the 
base class for GtkScrollbar), this gives you the chance, when
the user clicks the arrows or drags the thumb, to adjust
the bounds and/or page size *before* GTK+ clamps the position.

So, it should be pretty trivial to make the thumb shrink as the 
user drags past the end position of the scrollbar.

Regards,
                                        Owen

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

> >     > 3.  Make the GTK scrollbar more customizable so that it can optionally
> >     >     handle a character based approach and hence behave, within Emacs,
> >     >     more like the native scrollbar than the pixel based variant of the
> >     >     GTK scrollbar.
> > 
> >     I think this is the only reasonable solution.
> > 
> > I agree with Miles--this is the only right way.
> > 
> > Owen, would you please implement this facility in the GTK scroll bar?
> 
> I don't think there has been a satisfactory explanation of how you
> are going to deal with minimum size issues; which for some themes
> occur on quite moderately sized buffers. (As I said earlier, for
> Red Hat's default theme, the minimum scrollbar thumb size is
> ~30 pixels)

IIUC, the scrollbar widget has the following:

	total-size
	minimum thumb size
	thumb size
	thumb position

Where minimum-thumb-size is (for all intents and purposes here) a constant.
Let's simplify things and subtract minimum thumb size from the current
thumb size and from the total, we get:

	total-size
	thumb size
	thumb position

where
	
	0 <= thumb-size <= total-size
	thumb-size + thumb-position <= total-size

What we need is that when the mouse is moved such that
thumb-size+thumb-position would become larger than total-size,
[the scrollbar should behave as if] thumb-size is reduced to
total-size - thumb-position.

> I also am not convinced that the behavior is right from the point of
> view of a user; the ends of the scrollbar should be the ends
> of the scrollbar.

Total agreement ;-) : the user shouldn't be prevented from moving the
thumb-position to the end (i.e. to toal-size) just because the thumb-size
is currently non-zero.

> However, I was reminded this morning that a facility that allows
> you to implement your desired behavior was actually added prior
> to GTK+-2.2.
> 
> If you connect to the "adjust_bounds" signal on GtkRange (the 
> base class for GtkScrollbar), this gives you the chance, when
> the user clicks the arrows or drags the thumb, to adjust
> the bounds and/or page size *before* GTK+ clamps the position.
> 
> So, it should be pretty trivial to make the thumb shrink as the 
> user drags past the end position of the scrollbar.

That sounds like it might indeed do the trick.


	Stefan

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Mon, 2003-04-07 at 12:57, Stefan Monnier wrote:
> > >     > 3.  Make the GTK scrollbar more customizable so that it can optionally
> > >     >     handle a character based approach and hence behave, within Emacs,
> > >     >     more like the native scrollbar than the pixel based variant of the
> > >     >     GTK scrollbar.
> > > 
> > >     I think this is the only reasonable solution.
> > > 
> > > I agree with Miles--this is the only right way.
> > > 
> > > Owen, would you please implement this facility in the GTK scroll bar?
> > 
> > I don't think there has been a satisfactory explanation of how you
> > are going to deal with minimum size issues; which for some themes
> > occur on quite moderately sized buffers. (As I said earlier, for
> > Red Hat's default theme, the minimum scrollbar thumb size is
> > ~30 pixels)
> 
> IIUC, the scrollbar widget has the following:
> 
> 	total-size
> 	minimum thumb size
> 	thumb size
> 	thumb position
> 
> Where minimum-thumb-size is (for all intents and purposes here) a constant.
> Let's simplify things and subtract minimum thumb size from the current
> thumb size and from the total, we get:
> 
> 	total-size
> 	thumb size
> 	thumb position
>
> where
> 	
> 	0 <= thumb-size <= total-size
> 	thumb-size + thumb-position <= total-size

This isn't a "simplification", it is a different algorithm
from what GTK+ uses. The scrollbar thumb size in GTK+
is:

 MAX (min_size, total_size * document_page_size/document_size)

Not:

 min_size + (total_size - min_size) * document_page_size / document_size

The difference between these two is substantial. It's
possible to fake your algorithm using GTK+'s range
code, but it requires knowing both the minimum size in
pixels (easy to determine as a style property) and the
trough size in pixels (a complicated function of style
properties and the allocated size of the range.)

Regards,
                                                Owen

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

> > IIUC, the scrollbar widget has the following:
> > 
> > 	total-size
> > 	minimum thumb size
> > 	thumb size
> > 	thumb position
> > 
> > Where minimum-thumb-size is (for all intents and purposes here) a constant.
> > Let's simplify things and subtract minimum thumb size from the current
> > thumb size and from the total, we get:
> > 
> > 	total-size
> > 	thumb size
> > 	thumb position
> >
> > where
> > 	
> > 	0 <= thumb-size <= total-size
> > 	thumb-size + thumb-position <= total-size
> 
> This isn't a "simplification", it is a different algorithm
> from what GTK+ uses. The scrollbar thumb size in GTK+
> is:
> 
>  MAX (min_size, total_size * document_page_size/document_size)

[ I assume that total_size = document_size to simplify the discussion ]

So if min_size is 10, total_size is 100 and page_size is 1, how does
the user get to see the last page ?


	Stefan

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Mon, 2003-04-07 at 14:38, Stefan Monnier wrote:
> > > IIUC, the scrollbar widget has the following:
> > > 
> > > 	total-size
> > > 	minimum thumb size
> > > 	thumb size
> > > 	thumb position
> > > 
> > > Where minimum-thumb-size is (for all intents and purposes here) a constant.
> > > Let's simplify things and subtract minimum thumb size from the current
> > > thumb size and from the total, we get:
> > > 
> > > 	total-size
> > > 	thumb size
> > > 	thumb position
> > >
> > > where
> > > 	
> > > 	0 <= thumb-size <= total-size
> > > 	thumb-size + thumb-position <= total-size
> > 
> > This isn't a "simplification", it is a different algorithm
> > from what GTK+ uses. The scrollbar thumb size in GTK+
> > is:
> > 
> >  MAX (min_size, total_size * document_page_size/document_size)
> 
> [ I assume that total_size = document_size to simplify the discussion ]

> So if min_size is 10, total_size is 100 and page_size is 1, how does
> the user get to see the last page ?

The 0-99 possible values for position in the document are mapped
linearly onto the 0-90 possible values for the position of the
slider thumb.

Regards,
                                               Owen

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

> > > > IIUC, the scrollbar widget has the following:
> > > > 
> > > > 	total-size
> > > > 	minimum thumb size
> > > > 	thumb size
> > > > 	thumb position
> > > > 
> > > > Where minimum-thumb-size is (for all intents and purposes here) a constant.
> > > > Let's simplify things and subtract minimum thumb size from the current
> > > > thumb size and from the total, we get:
> > > > 
> > > > 	total-size
> > > > 	thumb size
> > > > 	thumb position
> > > >
> > > > where
> > > > 	
> > > > 	0 <= thumb-size <= total-size
> > > > 	thumb-size + thumb-position <= total-size
> > > 
> > > This isn't a "simplification", it is a different algorithm
> > > from what GTK+ uses. The scrollbar thumb size in GTK+
> > > is:
> > > 
> > >  MAX (min_size, total_size * document_page_size/document_size)
> > 
> > [ I assume that total_size = document_size to simplify the discussion ]
> 
> > So if min_size is 10, total_size is 100 and page_size is 1, how does
> > the user get to see the last page ?
> 
> The 0-99 possible values for position in the document are mapped
> linearly onto the 0-90 possible values for the position of the
> slider thumb.

My point exactly:
for all intents and purposes (other than actual drawing on
the screen which you might care about but we don't), we can
subtract 10 from all sizes and pretend the total_size is 90
and minimum_size is 0 (and can thus be ignored).


	Stefan

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Mon, 2003-04-07 at 15:02, Stefan Monnier wrote:
> > > > > IIUC, the scrollbar widget has the following:
> > > > > 
> > > > > 	total-size
> > > > > 	minimum thumb size
> > > > > 	thumb size
> > > > > 	thumb position
> > > > > 
> > > > > Where minimum-thumb-size is (for all intents and purposes here) a constant.
> > > > > Let's simplify things and subtract minimum thumb size from the current
> > > > > thumb size and from the total, we get:
> > > > > 
> > > > > 	total-size
> > > > > 	thumb size
> > > > > 	thumb position
> > > > >
> > > > > where
> > > > > 	
> > > > > 	0 <= thumb-size <= total-size
> > > > > 	thumb-size + thumb-position <= total-size
> > > > 
> > > > This isn't a "simplification", it is a different algorithm
> > > > from what GTK+ uses. The scrollbar thumb size in GTK+
> > > > is:
> > > > 
> > > >  MAX (min_size, total_size * document_page_size/document_size)
> > > 
> > > [ I assume that total_size = document_size to simplify the discussion ]
> > 
> > > So if min_size is 10, total_size is 100 and page_size is 1, how does
> > > the user get to see the last page ?
> > 
> > The 0-99 possible values for position in the document are mapped
> > linearly onto the 0-90 possible values for the position of the
> > slider thumb.
> 
> My point exactly:
> for all intents and purposes (other than actual drawing on
> the screen which you might care about but we don't), we can
> subtract 10 from all sizes and pretend the total_size is 90
> and minimum_size is 0 (and can thus be ignored).

The difference from your computations and the GTK+ computations
is that GTK+ only subtracts the minimum size from the total 
trough size, while you are also subtracting it from the thumb
size.

Regards,
                                         Owen

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

> > > The 0-99 possible values for position in the document are mapped
> > > linearly onto the 0-90 possible values for the position of the
> > > slider thumb.

By whom ?  The GTK library or the client application ?
If it's done by the library, then the application doesn't even
need to care about the minimum_size, right ?

> > My point exactly:
> > for all intents and purposes (other than actual drawing on
> > the screen which you might care about but we don't), we can
> > subtract 10 from all sizes and pretend the total_size is 90
> > and minimum_size is 0 (and can thus be ignored).
> 
> The difference from your computations and the GTK+ computations
> is that GTK+ only subtracts the minimum size from the total
> trough size, while you are also subtracting it from the thumb
> size.

But as long as that minimum_size is available to the client
application, the client can also do the subtraction and
forget about it.

My analysis was not meant to show how things work in GTK
but how Emacs likes to look at them.  As long as it's possible
for Emacs to look at them that way, all is fine.
The actual appearance is not really important.


	Stefan

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    I don't think there has been a satisfactory explanation of how you
    are going to deal with minimum size issues; which for some themes
    occur on quite moderately sized buffers. (As I said earlier, for
    Red Hat's default theme, the minimum scrollbar thumb size is
    ~30 pixels)

I see how the minimum thumb size will sometimes give a misleading idea
of what fraction of the file is visible.  That can happen even without
overscrolling, but whether it is a problem is a matter people might
disagree about.

Aside form that, what issue is there with minimum size?

    If you connect to the "adjust_bounds" signal on GtkRange (the 
    base class for GtkScrollbar), this gives you the chance, when
    the user clicks the arrows or drags the thumb, to adjust
    the bounds and/or page size *before* GTK+ clamps the position.

Thanks.  Jan, could you see if this method works?

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Mon, 2003-04-07 at 22:30, Richard Stallman wrote:
>     I don't think there has been a satisfactory explanation of how you
>     are going to deal with minimum size issues; which for some themes
>     occur on quite moderately sized buffers. (As I said earlier, for
>     Red Hat's default theme, the minimum scrollbar thumb size is
>     ~30 pixels)
> 
> I see how the minimum thumb size will sometimes give a misleading idea
> of what fraction of the file is visible.  That can happen even without
> overscrolling, but whether it is a problem is a matter people might
> disagree about.
> 
> Aside form that, what issue is there with minimum size?

The problem I see with a minimum size is that the technique of 
shrinking the thumb to represent overscrolling won't work if the
scrollbar thumb is already at its minimum size.

Regards,
                                         Owen

Re: Gtk scrollbar: thumb too short

[Miles Bader]

On Tue, Apr 08, 2003 at 10:56:59AM -0400, Owen Taylor wrote:
> The problem I see with a minimum size is that the technique of 
> shrinking the thumb to represent overscrolling won't work if the
> scrollbar thumb is already at its minimum size.

Then people won't be able to overscroll using the scrollbar in that case.

I don't think it matters that much, really, and it certainly isn't a reason
to not use such a natural method for overscrolling in the cases where it
_does_ work.  If someone can think of a better method that _always works,
great, but so far this is the best.

[I now feel certain that the current method used in emacs/gtk for
overscrolling (leaving extra empty space at the end to allow overscrolling)
is wrong, because I keep being annoyed that it doesn't clearly indicate the
end-of-buffer-shown condition]

-Miles
-- 
We are all lying in the gutter, but some of us are looking at the stars.
-Oscar Wilde

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    The problem I see with a minimum size is that the technique of 
    shrinking the thumb to represent overscrolling won't work if the
    scrollbar thumb is already at its minimum size.

That depends on how it is implemented.  The minimum size should apply
to the "whole thumb", which includes the part that is virtually beyond
the end of the trough.

Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Tue, 2003-04-08 at 21:58, Richard Stallman wrote:
>     The problem I see with a minimum size is that the technique of 
>     shrinking the thumb to represent overscrolling won't work if the
>     scrollbar thumb is already at its minimum size.
> 
> That depends on how it is implemented.  The minimum size should apply
> to the "whole thumb", which includes the part that is virtually beyond
> the end of the trough.

My opinion about a scrollbar where by user action or programmatic
action, the scrollbar may be scrolled so that there is nothing
left to click on, is: if you want such a scrollbar, you can write it
yourself. GtkScrollbar will not do that.

Regards,
                                            Owen

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

If Owen refuses to cooperate, then we could make a modified version of
GtkScrollbar for use in Emacs.  But that might be too much work for
us, not knowing the code.

The alternative that the thumb reaches the bottom only with maximum
overscrolling is bad in several ways.  I explained the problem that we
get with a large file such as etc/NEWS: you cannot drag the thumb to
see the end of the file.  If the thumb is at the bottom, you see no
text.  If the thumb is one pixel up, you are looking at text quite a
ways from the end of the file.

I just thought of another alternative.  The thumb could reach the bottom
when ZV reaches the bottom of the screen; then, if you overscroll, the
thumb would not move.  In other words, overscrolling would not be indicated
by the thumb.

This is obviously problematical, but I think it is less problematical
than the other alternative.

Jan, would you like to try this?

Re: Gtk scrollbar: thumb too short

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> I just thought of another alternative.  The thumb could reach the bottom
> when ZV reaches the bottom of the screen; then, if you overscroll, the
> thumb would not move.  In other words, overscrolling would not be indicated
> by the thumb.
> 
> This is obviously problematical, but I think it is less problematical
> than the other alternative.

Um, couldn't it do this only when the thumb actually reaches the minimum
size?  So for a buffer where the thumb was larger than minimum, you'd
get the nice shrinking behavior.

Since a thumb at minimum size would often be pretty unusable if it got
any smaller anyway, this seems like a reasonable compromise to me.

-Miles
-- 
Quidquid latine dictum sit, altum viditur.

Re: Gtk scrollbar: thumb too short

[Jan D.]

>     I don't think there has been a satisfactory explanation of how you
>     are going to deal with minimum size issues; which for some themes
>     occur on quite moderately sized buffers. (As I said earlier, for
>     Red Hat's default theme, the minimum scrollbar thumb size is
>     ~30 pixels)
> 
> I see how the minimum thumb size will sometimes give a misleading idea
> of what fraction of the file is visible.  That can happen even without
> overscrolling, but whether it is a problem is a matter people might
> disagree about.
> 
> Aside form that, what issue is there with minimum size?
> 
>     If you connect to the "adjust_bounds" signal on GtkRange (the 
>     base class for GtkScrollbar), this gives you the chance, when
>     the user clicks the arrows or drags the thumb, to adjust
>     the bounds and/or page size *before* GTK+ clamps the position.
> 
> Thanks.  Jan, could you see if this method works?

I will try.

	Jan D.

Re: Gtk scrollbar: thumb too short

[Jan D.]

> If Owen refuses to cooperate, then we could make a modified version of
> GtkScrollbar for use in Emacs.  But that might be too much work for
> us, not knowing the code.
> 
> The alternative that the thumb reaches the bottom only with maximum
> overscrolling is bad in several ways.  I explained the problem that we
> get with a large file such as etc/NEWS: you cannot drag the thumb to
> see the end of the file.  If the thumb is at the bottom, you see no
> text.  If the thumb is one pixel up, you are looking at text quite a
> ways from the end of the file.

How is different from the native scrollbar?  When I drag the thumb with
mouse-2 in the native scrollbar to the end, I don't see any text, it has
been overscrolled out of view.

> I just thought of another alternative.  The thumb could reach the bottom
> when ZV reaches the bottom of the screen; then, if you overscroll, the
> thumb would not move.  In other words, overscrolling would not be indicated
> by the thumb.
> 
> This is obviously problematical, but I think it is less problematical
> than the other alternative.
> 
> Jan, would you like to try this?

I will try if the adjust_bounds tick doesn't work out.

	Jan D.

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    > The alternative that the thumb reaches the bottom only with maximum
    > overscrolling is bad in several ways.  I explained the problem that we
    > get with a large file such as etc/NEWS: you cannot drag the thumb to
    > see the end of the file.  If the thumb is at the bottom, you see no
    > text.  If the thumb is one pixel up, you are looking at text quite a
    > ways from the end of the file.

    How is different from the native scrollbar?  When I drag the thumb with
    mouse-2 in the native scrollbar to the end, I don't see any text, it has
    been overscrolled out of view.

That sounds like exactly the alternative I am criticizing.

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    > I just thought of another alternative.  The thumb could reach the bottom
    > when ZV reaches the bottom of the screen; then, if you overscroll, the
    > thumb would not move.  In other words, overscrolling would not be indicated
    > by the thumb.
    > 
    > This is obviously problematical, but I think it is less problematical
    > than the other alternative.

    Um, couldn't it do this only when the thumb actually reaches the minimum
    size?  So for a buffer where the thumb was larger than minimum, you'd
    get the nice shrinking behavior.

If we implement the shrinking behavior ourselves, we could shrink
it as much as we like--we could implement the minimum size as pertaining
to the whole thumb including the part that's off screen.

The question is what to do if that is more work than we want to do.

Yes, we could do what you suggest.

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Richard Stallman wrote (in response to Jan D.):

       How is different from the native scrollbar?  When I drag the thumb with
       mouse-2 in the native scrollbar to the end, I don't see any text, it has
       been overscrolled out of view.

   That sounds like exactly the alternative I am criticizing.

If with the native scrollbar, you scroll till the thumb hits the
bottom for the first time, you see the last screenfull of real text.
If you keep scrolling till the thumb has minimal size, then the last
line you can put point on is at the top. If the buffer ends in a
newline, that means that there is no text on the screen.

Clearly, if you allow overscrolling to put the last line point can be
on at the top, then, by *definition*, if you scroll as far as you
can scroll, that is where you are going to end up.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Jan D.]

> If with the native scrollbar, you scroll till the thumb hits the
> bottom for the first time, you see the last screenfull of real text.
> If you keep scrolling till the thumb has minimal size, then the last
> line you can put point on is at the top. If the buffer ends in a
> newline, that means that there is no text on the screen.

Wht do you mean by "the first time"?  If I drag down the thumb to the
bottom, it is the first time it is there, but I do not see any text,
it has been overscrolled out of view.

I do not understand what the desired behaviour is supposed to be,
versus how it really works with the native scroll bar.

	Jan D.

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Jan D. wrote:

   Wht do you mean by "the first time"?  If I drag down the thumb to the
   bottom, it is the first time it is there, but I do not see any text,
   it has been overscrolled out of view.

   I do not understand what the desired behaviour is supposed to be,
   versus how it really works with the native scroll bar.

There is some "precision work" required, no doubt about that.  You
have to drag slowly and carefully, you can not just "yank".  Actually,
that is a problem that is very difficult (or impossible) to get
around.  (It is one of the things Owen objected to.)  Dragging with
mouse-2 is not very handy for precision work.  (Actually, it is
completely impossible for large buffers.)

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Jan D. wrote:

   Wht do you mean by "the first time"?

I mean the first time that the *bottom* end of the thumb hits the
bottom.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Kai Großjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> There is some "precision work" required, no doubt about that.  You
> have to drag slowly and carefully, you can not just "yank".

Dragging the thumb to the beginning of the buffer does not require
precision work.  So it would be nice if it wouldn't require precision
work for dragging to the end of the buffer, either.

Ideas:

* Some window managers offer "attraction" or "resistance".  Attraction
  means: when one window edge gets close to another window's edge or
  to the edge of the screen, the window is warped so that the two
  edges are adjacent.  Resistance means: when one window edge becomes
  adjacent to another window edge or the edge of the screen, moving
  the mouse further by a few pixels does not move the window.  One has
  to move the mouse several pixels before the window starts moving
  again.

  This could be adapted to the end of buffer condition: you drag the
  thumb downwards.  As soon as end of buffer becomes visible, dragging
  the mouse down by a few more pixels doesn't change the buffer
  (thumb) position.  You have to move the mouse down a minimum number
  of pixels to make the thumb move again.

  Mouse pointer and thumb could become out of sync, as the mouse
  pointer moves down without the thumb moving.  The visual
  inconsistency might be bad.  For a window near the bottom of the
  screen, this could become a functional problem, even.

  Window managers often solve this by moving the window "a lot" when
  attraction/resistance is overcome.  For example, let's say the
  resistance is 10 pixels, then moving a window 1, 2, ..., 10 pixels
  offscreen is not possible, the minimum number of pixels to move it
  offscreen is 10.  Alas, this solution does not seem feasible with
  the scrollbar since there is not much left to scroll after end of
  buffer becomes visible.

* If end of buffer is not visible when scrolling-by-dragging starts,
  then overscrolling is not possible.  Only if end of buffer is
  visible when scrolling-by-dragging starts, then overscrolling
  becomes possible.

  Users have to drag twice to achieve overscrolling.  A potential
  problem with this approach occurs when the thumb warps to the
  position of the mouse pointer when dragging starts, as it happens
  for the native scrollbar.  Then users would have to hit the right
  spot on the thumb to ensure that end of buffer remains visible when
  scrolling starts.  But I think that this problem does not occur
  with the Motif and Gtk scrollbars; there it does not matter where
  exactly one hits the thumb when starting to drag-scroll.  Am I
  wrong?

What do people think?
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: Gtk scrollbar: thumb too short

[Stefan Monnier]

> Dragging the thumb to the beginning of the buffer does not require
> precision work.  So it would be nice if it wouldn't require precision
> work for dragging to the end of the buffer, either.

I have no idea what you guys are talking about, but as someone who's
spent a fair amount of time on the Emacs support for Motif and Xaw3d
scrollbars, I think that any dragging behavior that

- doesn't flicker majorly
- can always make (point-max) visible
- doesn't impose an unnatural thumb size and position
  (i.e. unlike the current Motif situation)
- is not much slower than the current code

is already pretty difficult to obtain, so talking about anything finer
than that seems totally pointless.


	Stefan

Re: Gtk scrollbar: thumb too short

[Andreas Schwab]

kai.grossjohann@gmx.net (Kai Großjohann) writes:

|> Luc Teirlinck <teirllm@dms.auburn.edu> writes:
|> 
|> > There is some "precision work" required, no doubt about that.  You
|> > have to drag slowly and carefully, you can not just "yank".
|> 
|> Dragging the thumb to the beginning of the buffer does not require
|> precision work.  So it would be nice if it wouldn't require precision
|> work for dragging to the end of the buffer, either.

I don't see a problem here.  From Emacs' POV the buffer is scrolled to
the far end if (point-max) equals (window-start).  The fact that this is
further than what other editors can achieve only shows the superiority of
Emacs. :-)

You'll always need precision to position to a specific position except the
beginning of buffer.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Gtk scrollbar: thumb too short

[Kai Großjohann]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> I have no idea what you guys are talking about, but as someone who's
> spent a fair amount of time on the Emacs support for Motif and Xaw3d
> scrollbars, I think that any dragging behavior that
>
> - doesn't flicker majorly
> - can always make (point-max) visible
> - doesn't impose an unnatural thumb size and position
>   (i.e. unlike the current Motif situation)
> - is not much slower than the current code
>
> is already pretty difficult to obtain, so talking about anything finer
> than that seems totally pointless.

Alright.  I haven't looked into it at all.

Another idea that might be easy to implement and that would improve
the current situation is to somehow indicate the end-of-buffer
condition better.  So, how about using different bg color for the
part of the trough that corresponds to overscrolling?  Then I could
see where in the buffer I am.
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: Gtk scrollbar: thumb too short

[Robert J. Chassell]

   I do not understand what the desired behaviour is supposed to be,
   versus how it really works with the native scroll bar.

I just visited a test file.  The behavior I expect and desire is how
it really works.  When I overscroll to the end, Emacs shows me the
last line of the buffer.

This means that if the last line of the buffer is blank, I see nothing
but the cursor that I have put at the end of the buffer.  This occurs
when the buffer ends in a newline.  If, on the other hand, the last
line contains text, I see both the text and the cursor that I have put
at the end of the buffer.

This is the same behavior as occurs in GNU Emacs 20.7 (I just checked).

This is using

    Today's CVS snapshot, Fri, 2003 Apr 11  12:37 UTC
    GNU Emacs 21.3.50.288 (i686-pc-linux-gnu, X toolkit)
    LUCID toolkit
    started with

      /usr/local/bin/emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

    and GNU Emacs 20.7, native toolkit, with a large ~/.emacs file.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk scrollbar: thumb too short

[Kai Großjohann]

Andreas Schwab <schwab@suse.de> writes:

> I don't see a problem here.  From Emacs' POV the buffer is scrolled to
> the far end if (point-max) equals (window-start).  The fact that this is
> further than what other editors can achieve only shows the superiority of
> Emacs. :-)

Har, har.

So you can scroll to a spot where the window is (almost) empty real
quick.  This does not appear to be a very useful spot to scroll to.
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: Gtk scrollbar: thumb too short

[Robert J. Chassell]

kai.grossjohann@gmx.net wrote:

    Dragging the thumb to the beginning of the buffer does not require
    precision work.  So it would be nice if it wouldn't require
    precision work for dragging to the end of the buffer, either.

In most of the buffers I use, going to the end does not require
precision work; I just checked!

Precision work may be required if you visit a long buffer, such as the
NEWS buffer, and you are going to a point that is not quite the end.
However, I don't think the scroll bar and thumb should be adapted to
this kind of positioning.

(Note that the scroll bar and thumb work fine for positioning text in
a buffer as short as this *mail* buffer.)

Instead of using the scroll bar and thumb for precision work in a long
buffer, I use the <down> arrow key, which I have bound to:

    (defun scroll-forward-one-line ()
      "Scroll the text up one line.
    A replacement for the three keystroke sequence
    C-u 1 C-v."
      (interactive)
      (scroll-up 1))

  (global-set-key [down] 'scroll-forward-one-line)  ; Down arrow key

and the nearly equivalent `scroll-backward-one-line', which I have
bound to the <up> arrow key.  (Interestingly, the `(scroll-up 1)'
expression does not consider a line consisting of a single, final
newline as the last line of a buffer, but the line before it, which
may also be a single newline.  I never noticed this characteristic
before.)

When I am testing a `plain vanilla' GNU Emacs stated with 

    emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

I simply use the necessary three keystroke sequence.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk scrollbar: thumb too short

[Robert J. Chassell]

   Har, har.

   So you can scroll to a spot where the window is (almost) empty real
   quick.  This does not appear to be a very useful spot to scroll to.

It is extremely useful, since it enables the user to put the bottom of
the buffer at or near the top of the window.  I do this all the time.

I hate programs whose user interface prevents me from moving what I am
reading or typing towards the top of the window.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk scrollbar: thumb too short

[Kai Großjohann]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> kai.grossjohann@gmx.net wrote:
>
>     Dragging the thumb to the beginning of the buffer does not require
>     precision work.  So it would be nice if it wouldn't require
>     precision work for dragging to the end of the buffer, either.
>
> In most of the buffers I use, going to the end does not require
> precision work; I just checked!

I apologize for the unclear wording.

It is easy to drag the thumb of the scrollbar such that end of buffer
is shown in the first line of the window.  This means that the window
is (nearly) empty.

But I would prefer that it would be easy to drag the thumb of the
scrollbar such that end of buffer is shown in the *last* line of the
window.  IMVHO that's a more interesting position to scroll to.

The big problem is: how to make it *easy* to scroll end of buffer to
the last window line, but *possible* to scroll end of buffer to any
other window line, including the first?
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

>From my earlier message:

   There is some "precision work" required, no doubt about that.  You
   have to drag slowly and carefully, you can not just "yank".

I should clarify that I said this to explain, not to complain.

Kai Grossjohann wrote:

   But I would prefer that it would be easy to drag the thumb of the
   scrollbar such that end of buffer is shown in the *last* line of the
   window.

Yes, but why not use M- > , or, the END key, after rebinding it to
(end-of-buffer).  (To people who know about C-e, the default binding
of END is useless.)  Scrolling with mouse-2 is not meant for precision
work with the scrollbar, mouse-1 and mouse-3 are (for the native
scrollbar).

Sincerely,

Luc.

NEWS and invisible text

[Stefan Monnier]

The NEWS file says:

   ** Only one of the beginning or end of an invisible, intangible region is
   considered an acceptable value for point; which one is determined by
   examining how the invisible/intangible properties are inherited when new
   text is inserted adjacent to them.  If text inserted at the beginning would
   inherit the invisible/intangible properties, then that position is
   considered unacceptable, and point is forced to the position following the
   invisible/intangible text.  If text inserted at the end would inherit the
   properties, then the opposite happens.
  
   Thus, point can only go to one end of an invisible, intangible region, but
   not the other one.  This prevents C-f and C-b from appearing to stand still
   on the screen.  

I'm not sure what it refers to, and I think it should make it more
clear in which way it's different from the previous behavior.

Also I'd like to add the following (although better working would
be appreciated), which is about a different feature (AFAIK).  Any
idea how to make the two more understandable, especially w.r.t
each other ?

   ** The code that forced point to move out of images and composition
   has been generalized to apply to overlays as well and to invisible text.
   This makes it generally unnecessary to mark invisible text as intangible,
   which is particularly good due to the fact that the intangible property
   can often have unexpected side-effects because the property applies
   to everything (including `goto-char', ...) whereas this new code is
   only run after post-command-hook and thus does not care about intermediate
   states.
	

-- Stefan

Re: Gtk scrollbar: thumb too short

[Kai Großjohann]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>    So you can scroll to a spot where the window is (almost) empty real
>    quick.  This does not appear to be a very useful spot to scroll to.
>
> It is extremely useful, since it enables the user to put the bottom of
> the buffer at or near the top of the window.  I do this all the time.

Please note that I did not want to suggest to turn overscrolling off.

I just want to make it so that scrolling beginning of buffer to the
first window line and scrolling end of buffer to the last window line
are about equally easy.  Scrolling end of buffer to the first window
line should still be possible, just not as easy as the other two.  (It
might still be easier than scrolling line 4711, say, to the first
window line.)
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: Gtk scrollbar: thumb too short

[Robert J. Chassell]

kai.grossjohann@gmx.net  writes:

   But I would prefer that it would be easy to drag the thumb of the
   scrollbar such that end of buffer is shown in the *last* line of the
   window.  IMVHO that's a more interesting position to scroll to.

You could change the `end-of-buffer' command so that you can set a
variable that causes it to stop on the last line instead of three
lines from the end, as it does now.  (I recommend using a variable
because I like the current behavior, which enables me to write several
extra lines on a buffer without the buffer text moving in the window.)

   The big problem is: how to make it *easy* to scroll end of buffer
   to the last window line ...

I bind the `end-of-buffer' command to the <end> key, so it is easy to
scroll to the position I like.  If you change the command, with a
variable, then it will be equally easy for you to scroll to the place
you want.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk scrollbar: thumb too short

[Robert J. Chassell]

kai.grossjohann@gmx.net wrote:

   .... (It might still be easier than scrolling line 4711, say, to
   the first window line.)

I just scrolled line 4711 to the first window line using 7 keystrokes,
four of which were the number.  Based on the frequency at which I do
things like this, I don't think this need be improved on.

The keystrokes were

    `C-c C-g', which I have bound to `goto-line'.

     4711          -- the line number

     `<f9>', which I have bound to a command that I call
     `line-to-top-of-window', which is an interactive function
     definition for the expression `(recenter 0)'.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Gtk scrollbar: thumb too short

[Miles Bader]

On Fri, Apr 11, 2003 at 10:42:21PM +0200, Kai Gro?johann wrote:
> I just want to make it so that scrolling beginning of buffer to the
> first window line and scrolling end of buffer to the last window line
> are about equally easy.  Scrolling end of buffer to the first window
> line should still be possible, just not as easy as the other two.

Given the `squishy scrollbar thumb' model, I think what you'd end up with is
that scrolling the last line of the buffer to _approximately_ the last line
of the screen would be easy -- because you have obvious visual feedback, it
would be pretty intuitive to stop before the maximum overscroll, but probably
not easy to do it _exactly_ (of course I'm talking about large buffers; with
small buffers, the large thumb makes everything pretty easy).

However, I think `approximately' is good enough; people don't actually need
to position the text exactly, they just need to get the end of the buffer
with enough text visible to be useful for editing, and from my little
experience with the emacs non-toolkit scrollbars, this is not a problem
(typically I initially overscroll a lot by moving the thumb quickly to the
end, but backing up a bit to put more text on the screen is a natural and
easy action because of the `obviousness' of the visual feedback).

The previous suggestion (from Luc?) about implementing `stickiness' might be
a good refinement to this though -- have the scrollbar `stick' at the maximum
visible at end position for a while (IOW, there's a certain additional amount
of the scrollbar range that all maps to this one position).  This would make
positioning at the max-visible spot _very_ easy.

-miles
-- 
Run away!  Run away!

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Miles Bader wrote:

   The previous suggestion (from Luc?) about implementing `stickiness'

That was one of Kai's suggestions.  My point of view is that trying to
use scrolling with mouse-2 in large buffers for precision work quite
simply does not work.  I use mouse-2 to get more or less the position
I want.  Most of the time that is good enough.  Otherwise, I use
mouse-1 or -3 (native scrollbar) or C-l with numeric argument.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Miles Bader]

On Fri, Apr 11, 2003 at 07:47:01PM -0500, Luc Teirlinck wrote:
>    The previous suggestion (from Luc?) about implementing `stickiness'
> 
> That was one of Kai's suggestions.  My point of view is that trying to
> use scrolling with mouse-2 in large buffers for precision work quite
> simply does not work.  I use mouse-2 to get more or less the position
> I want.  Most of the time that is good enough.

YEah, I agree -- scrollbar dragging is a rough control at best, so it's
really only important that it be close enough to make people happy.

I think that the beginning- and end- of buffer are special cases however, so
it's reasonable to pay a bit of extra attention to them, and that `squishy
thumb + sticky-point at the last-line-of-buffer-last-line-screen' method
would very naturally meet all the various goals though.

-Miles

-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Kai Grossjohann wrote:

   So, how about using different bg color for the
   part of the trough that corresponds to overscrolling?

If you use character based counting, there is no such part of the
trough.  The overscrolled piece contains no characters and hence has
size 0 on the trough.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Kai Großjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Kai Grossjohann wrote:
>
>    So, how about using different bg color for the
>    part of the trough that corresponds to overscrolling?
>
> If you use character based counting, there is no such part of the
> trough.  The overscrolled piece contains no characters and hence has
> size 0 on the trough.

??

With the old Gtk scrollbar behavior, you can scroll end of buffer to
the last window line, and then there will be some area of the trough
visible below the thumb.

I was suggesting to color this area.  It is clearly non-empty, as
anyone can see by trying out the Gtk scrollbar.  (I changed back from
Gtk to the native scrollbar some days ago, so if the Gtk scrollbar
changed in the last 4 days, then disregard my ranting...)
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: Gtk scrollbar: thumb too short

[Miles Bader]

On Sat, Apr 12, 2003 at 10:56:51AM +0200, Kai Gro?johann wrote:
> With the old Gtk scrollbar behavior, you can scroll end of buffer to
> the last window line, and then there will be some area of the trough
> visible below the thumb.
> 
> I was suggesting to color this area.  It is clearly non-empty, as
> anyone can see by trying out the Gtk scrollbar.

I guess that would be better than no change at all, but I think it's much
worse than the other solutions being dicussed -- I think it would just feel
wrong (as the current gtk scrollbar does in emacs).

I suspect it's also probably a pain (or impossible) to implement, as the
scrollbar is drawn by the theme, which emacs has little control over (and as
themes have a fair amount of flexibility in drawing, if emacs tried to draw
something itself, it would almost certainly screw it up with some themes).

-Miles
-- 
97% of everything is grunge

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Kai Grossjohann wrote:

   With the old Gtk scrollbar behavior, you can scroll end of buffer to
   the last window line, and then there will be some area of the trough
   visible below the thumb.

   I was suggesting to color this area.  It is clearly non-empty, as
   anyone can see by trying out the Gtk scrollbar.  (I changed back from
   Gtk to the native scrollbar some days ago, so if the Gtk scrollbar
   changed in the last 4 days, then disregard my ranting...)

If I understood the discussion on the subject correctly, Richard
decided to try to change that behavior to make the GTK scrollbar
behave more like the native one.  (Again, unless I misunderstood.)  As
I understood it, Jan is trying to implement Richard's proposal and
therefore, was trying to understand exactly how the native scrollbar
behaves.  If I understand correctly, the behavior has not changed over
the last few days, but it is likely to change in the future.

Of course some (Owen in particular) may prefer the old behavior.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Kai Großjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> If I understood the discussion on the subject correctly, Richard
> decided to try to change that behavior to make the GTK scrollbar
> behave more like the native one.  (Again, unless I misunderstood.)  As
> I understood it, Jan is trying to implement Richard's proposal and
> therefore, was trying to understand exactly how the native scrollbar
> behaves.  If I understand correctly, the behavior has not changed over
> the last few days, but it is likely to change in the future.

Yeah, maybe it was silly of me to suggest such minor tweakings of the
old gtk scrollbar behavior, whereas Jan is presumably going to
implement a much better solution, rather than the kludge I've come up
with.

-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    If with the native scrollbar, you scroll till the thumb hits the
    bottom for the first time, you see the last screenfull of real text.
    If you keep scrolling till the thumb has minimal size, then the last
    line you can put point on is at the top. If the buffer ends in a
    newline, that means that there is no text on the screen.

That sounds like the behavior I am advocating.

Regardless of what character is at the end of the buffer,
you can always do (set-window-start (point-max)) and then
no text will be visible.  The data structure has this possibility,
so unless we write code to refuse to let the user do it, it can happen.

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

      This could be adapted to the end of buffer condition: you drag the
      thumb downwards.  As soon as end of buffer becomes visible, dragging
      the mouse down by a few more pixels doesn't change the buffer
      (thumb) position.  You have to move the mouse down a minimum number
      of pixels to make the thumb move again.

This is a good idea.

      Mouse pointer and thumb could become out of sync, as the mouse
      pointer moves down without the thumb moving.  The visual
      inconsistency might be bad.

I don't think that is a serious problem.  Also, it is possible to set
it up so that the mouse pointer on the screen doesn't start to move
until after the physical mouse has overcome the resistance.
That way there is no visial inconsistency.

      For a window near the bottom of the
      screen, this could become a functional problem, even.

The idea above avoids that problem too.

    * If end of buffer is not visible when scrolling-by-dragging starts,
      then overscrolling is not possible.  Only if end of buffer is
      visible when scrolling-by-dragging starts, then overscrolling
      becomes possible.

That seems worth a try.

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    I understood it, Jan is trying to implement Richard's proposal and
    therefore, was trying to understand exactly how the native scrollbar
    behaves.  If I understand correctly, the behavior has not changed over
    the last few days, but it is likely to change in the future.

There is some chance we will change the behavior of the native
scrollbar; people have proposed some interesting ideas.  However,
people have not yet implemented them, and if they do, we will have
to try them out before deciding whether to use them.  So I would
say the chance of a change is less than 50%.

Re: NEWS and invisible text

[Kevin Rodgers]

Stefan Monnier wrote:

> The NEWS file says:
> 
>    ** Only one of the beginning or end of an invisible, intangible region is
>    considered an acceptable value for point; which one is determined by
>    examining how the invisible/intangible properties are inherited when new
>    text is inserted adjacent to them. 


Is that determined by examining the front-sticky and rear-sticky properties?

>    If text inserted at the beginning would
>    inherit the invisible/intangible properties, then that position is
>    considered unacceptable, and point is forced to the position following the
>    invisible/intangible text.  If text inserted at the end would inherit the
>    properties, then the opposite happens.

What happens when both conditions are true?

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Richard Stallman wrote:

   There is some chance we will change the behavior of the native
   scrollbar; people have proposed some interesting ideas.  However,
   people have not yet implemented them, and if they do, we will have
   to try them out before deciding whether to use them.  So I would
   say the chance of a change is less than 50%.

If I understand correctly Kai made three proposals:

1. Implement stickiness.
2. Only allow overscrolling if the end of the buffer was visible at
   the start of scrolling.
3. Use the Motiv - current GTK behavior but color the piece of the
   scrollbar that corresponds to the empty space at the bottom
   differently.

If I understand correctly, you only considered 1. and 2. worth a try.

Personally, I only feel comfortable implementing 2. and only for the
native scrollbar.  (I am not familiar enough with the other
scrollbars.)

Below is a rough implementation, only meant for people to "play" with
to see if they like it.  If people are interested, I would make the
new behavior customizable and one could then decide what the default
behavior should be.  Note that my implementation only applies to the
native scrollbar.

Description of new behavior:

First time scrolling stops with the last screenfull of real text
visible, unless the end of the buffer is visible at the outset and
stays visible.  In other words, if you scroll up to see what is above
and scroll back down, you can not (immediately) overscroll.  To
overscroll, you have to first scroll to the bottom (unless you already
are there), grab the thumb (*not* click above the thumb) and scroll
down, without first scrolling up.

I personally would only recommend making the new behavior a
customizable option, with the old behavior the default.

Since this is just a rough implementation, I do not yet send a diff,
but instead the new versions of scroll-bar-drag and scroll-bar-drag-1.
One can put these in a file in emacs-lisp-mode, do C-M-x and start
playing.  Of course, like any new behavior, one first has to get used
to it, and then use it in some actual "real work", before one can
really judge.  The new behavior is meant for people who only
occasionally want to overscroll, and most of the time only want to
scroll to the end of the buffer.  In the final version, you will
always be able to temporarily (or on a buffer-by-buffer basis) change
your usual default, using the customizable variable I would define.
First, however, I want to check whether there is any interest.

===File ~/dragstuff.el======================================
(defun scroll-bar-drag-1 (event)
  (let* ((start-position (event-start event))
	 (window (nth 0 start-position))
	 (portion-whole (nth 2 start-position)))
    (save-excursion
      (set-buffer (window-buffer window))
      ;; Calculate position relative to the accessible part of the buffer.
      (goto-char (+ (point-min)
		    (scroll-bar-scale portion-whole
				      (- (point-max) (point-min)))))
      (beginning-of-line)
      (set-window-start window (point))
      (if (eq (window-end nil t) (point-max))
	  (when (and (boundp end-visible) (not end-visible))
	    (goto-char (point-max))
	    (beginning-of-line)
	    (recenter -1))
	(setq end-visible nil)))))

(defun scroll-bar-drag (event)
  "Scroll the window by dragging the scroll bar slider.
If you click outside the slider, the window scrolls to bring the slider there."
  (interactive "e")
  (let* (done
	 end-visible
	 (echo-keystrokes 0)
	 (end-position (event-end event))
	 (window (nth 0 end-position))
	 (before-scroll))
    (with-current-buffer (window-buffer window)
      (setq before-scroll point-before-scroll))
    (save-selected-window
      (select-window window)
      (setq end-visible (= (point-max) (window-end nil t)))
      (setq before-scroll
	    (or before-scroll (point))))
    (scroll-bar-drag-1 event)
    (track-mouse
      (while (not done)
	(setq event (read-event))
	(if (eq (car-safe event) 'mouse-movement)
	    (setq event (read-event)))
	(cond ((eq (car-safe event) 'scroll-bar-movement)
	       (scroll-bar-drag-1 event))
	      (t
	       ;; Exit when we get the drag event; ignore that event.
	       (setq done t)))))
    (sit-for 0)
    (with-current-buffer (window-buffer window)
      (setq point-before-scroll before-scroll))))

============================================================

Re: Gtk scrollbar: thumb too short

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> 1. Implement stickiness.
> 2. Only allow overscrolling if the end of the buffer was visible at
>    the start of scrolling.
> 3. Use the Motiv - current GTK behavior but color the piece of the
>    scrollbar that corresponds to the empty space at the bottom
>    differently.

(2) sounds like very annoying behavior (and I'll bet it would result in
a lot of user confusion -- it would probably seem to many people like
the overscrolling was simply flaky).

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Miles Bader wrote:

   (2) sounds like very annoying behavior (and I'll bet it would result in
   a lot of user confusion -- it would probably seem to many people like
   the overscrolling was simply flaky).

I am not necessarily recommending anything.  I gave a rough
implementation, so people could try it out.  Note that it might only
be a customizable option, with the old (native scrollbar) behavior
remaining the default.  Note also that (1) is just a pie in the sky
unless somebody volunteers to implement it (without creating other
trouble).

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Kai Großjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> First time scrolling stops with the last screenfull of real text
> visible, unless the end of the buffer is visible at the outset and
> stays visible.  In other words, if you scroll up to see what is above
> and scroll back down, you can not (immediately) overscroll.  To
> overscroll, you have to first scroll to the bottom (unless you already
> are there), grab the thumb (*not* click above the thumb) and scroll
> down, without first scrolling up.

What do you think about the following small change: whether
overscrolling is allowed only depends on eob visibility when the drag
starts.  That is, if eob is visible and I press the middle mouse
button, then I can drag up and down and still overscroll.

But maybe there was a reason you didn't do that?
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Kai Grossjohann wrote:

   What do you think about the following small change: whether
   overscrolling is allowed only depends on eob visibility when the drag
   starts.  That is, if eob is visible and I press the middle mouse
   button, then I can drag up and down and still overscroll.

   But maybe there was a reason you didn't do that?

I thought that if you started at the end and scrolled up to check
something and then scrolled back, you indicated no intention to
overscroll.  Rather, it would be likely that you just temporarily
wanted to see what was "upstairs" and scroll back to where you
started.  Otherwise, you would have scrolled down immediately.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Richard Stallman]

    First time scrolling stops with the last screenfull of real text
    visible, unless the end of the buffer is visible at the outset and
    stays visible.  In other words, if you scroll up to see what is above
    and scroll back down, you can not (immediately) overscroll.  To
    overscroll, you have to first scroll to the bottom (unless you already
    are there), grab the thumb (*not* click above the thumb) and scroll
    down, without first scrolling up.

I think the idea is worth trying.  I look forward to hearing people's
reactions.

Of course, this should only apply to Mouse-2.  It will also be
possible to overscroll using the keyboard and using Mouse-1.

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

Richard Stallman wrote:

       First time scrolling stops with the last screenfull of real text
       visible, unless the end of the buffer is visible at the outset and
       stays visible.  In other words, if you scroll up to see what is above
       and scroll back down, you can not (immediately) overscroll.  To
       overscroll, you have to first scroll to the bottom (unless you already
       are there), grab the thumb (*not* click above the thumb) and scroll
       down, without first scrolling up.

   I think the idea is worth trying.  I look forward to hearing people's
   reactions.

   Of course, this should only apply to Mouse-2.  It will also be
   possible to overscroll using the keyboard and using Mouse-1.

Everything applies only to scrolling with Mouse-2, nothing else is
affected.

My original implementation was, as I pointed out, only very rough.  I
discovered afterwards that it had some bugs related to continuation
lines and scrolling a non-selected window.  These bugs are easy to
fix, however.  I will send (probably before the end of the week) a
more "deluxe" version.  That version will include a customizable
variable with integer value, through which users can specify their own
preferred default limit for first time overscrolling with Mouse-2.  A
positive value N means that first time overscrolling always leaves at
least N screen-lines visible (if consistent with the fact that, of
course, the end must remain visible).  A negative value -N means to
recenter the last line of real text at -N, thus leaving (abs N) minus
1 empty lines at the bottom.  Thus, -1 shows the end with maximal
possible content visible.  To the other extreme a value of 1 only
makes a difference if the buffer ends in a newline, in which case it
avoids staring at an empty screen at the end of overscrolling.  As
always, however, if the user feels the irresistible urge to stare at
an empty screen anyway, then that can always be achieved by a second
scroll.

Sincerely,

Luc.

Re: Gtk scrollbar: thumb too short

[Luc Teirlinck]

I forgot to specify that, obviously, a value of 0 corresponds to the
present situation.  This could be kept as the default value.

Sincerely,

Luc.

Re: NEWS and invisible text

[Richard Stallman]

    >    ** Only one of the beginning or end of an invisible, intangible region is
    >    considered an acceptable value for point; which one is determined by
    >    examining how the invisible/intangible properties are inherited when new
    >    text is inserted adjacent to them. 


    Is that determined by examining the front-sticky and rear-sticky properties?

Yes.

    >    If text inserted at the beginning would
    >    inherit the invisible/intangible properties, then that position is
    >    considered unacceptable, and point is forced to the position following the
    >    invisible/intangible text.  If text inserted at the end would inherit the
    >    properties, then the opposite happens.

    What happens when both conditions are true?

I think you can't put point at either end, in that case.
But I didn't test it, I just read the code.  Want to test it?
Here's a rewrite that says what I think the code does.


** Only one of the beginning or end of an invisible, intangible region is
considered an acceptable value for point; which one is determined by
examining how the invisible/intangible properties are inherited when new
text is inserted adjacent to them.  (The `front-sticky' and `rear-sticky'
properties control this.)

If text inserted at the beginning would inherit the
invisible/intangible properties, then that position is considered
unacceptable, and point is forced to continue (if moving forwards, to
the position following the invisible/intangible text; if moving
backwards, to one position before).  If text inserted at the end would
inherit the properties, then that position is considered unacceptable,
and point is forced to keep moving (if moving backwards, to the
position preceding the invisible/intangible text; if moving forwards,
to one position later).