scrollbar (again)

scrollbar (again)

[Luc Teirlinck]

I am talking about either an emacs-21.3.50 configured with no options
(Xaw3d scroll bars, yesterday evening) or with ./configure
--without-toolkit-scroll-bars (native scrollbars, two days ago).

Do C-h i m emacs (just so we are talking about the same buffer).

Click with mouse-2 on the thumb (or slider, whatever you want to call
it) in the lower portion of the thumb, but clearly inside the thumb.
The idea is to start dragging the thumb around.  However, the buffer
immediately scrolls to some far away area.

Result of C-h k and click with mouse-2 on the thumb of the native
scrollbar:

<vertical-scroll-bar> <down-mouse-2> (translated from <down-mouse-2>)
runs the command scroll-bar-drag
   which is an interactive compiled Lisp function in `scroll-bar'.
It is bound to <vertical-scroll-bar> <down-mouse-2>.
(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.

Comment: we clicked *inside* the slider (thumb, whatever), no
automatic scrolling should have happened.

More surprises:
Result of C-h k and click with mouse-2 on the thumb of the Xaw3d
scrollbars:

<vertical-scroll-bar> <mouse-1> (translated from <mouse-1>) runs the
command scroll-bar-toolkit-scroll
   which is an interactive compiled Lisp function in `scroll-bar'.
It is bound to <vertical-scroll-bar> <mouse-1>.
(scroll-bar-toolkit-scroll EVENT)

Not documented.

Comment: mouse-1?  Is this normal?  I definitely clicked mouse-2.

Sincerely,

Luc.

Re: scrollbar (again)

[Kai Großjohann]

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

> Click with mouse-2 on the thumb (or slider, whatever you want to call
> it) in the lower portion of the thumb, but clearly inside the thumb.
> The idea is to start dragging the thumb around.  However, the buffer
> immediately scrolls to some far away area.

IIRC, the behavior in the no-toolkit case is similar to xterm.  That
is, the top of the thumb will be warped to where you clicked mouse-2.

I agree that this makes it difficult to start dragging.  It's
something I don't like about this kind of scrollbar.  Nevertheless, I
think it's still the best scrollbar there is, functionality-wise.

I also used to like the OpenView (XView? OpenLook?) scrollbar that
was used in OpenWindows applications of yore.  It made it easier to
drag but didn't have the nifty "scroll N lines" feature that the
no-toolkit scrollbar has.

These days, I rarely use the scrollbar and thus circumvent the
problem...
-- 
A preposition is not a good thing to end a sentence with.

Re: scrollbar (again)

[Luc Teirlinck]

Kai GrossJohann wrote:
   
   IIRC, the behavior in the no-toolkit case is similar to xterm.  That
   is, the top of the thumb will be warped to where you clicked mouse-2.

   I agree that this makes it difficult to start dragging.  It's
   something I don't like about this kind of scrollbar.  Nevertheless, I
   think it's still the best scrollbar there is, functionality-wise.

For the no-toolkit scrollbar the *top* of the slider (thumb, whatever)
moves to where you click with mouse-2.  In the case of the Xaw3d
scrollbar the *middle* moves to where you click.  So if you want to
use the scrollbar with mouse-2 to drag (without initial scrolling),
you have to grab it by the top for the native one and (more difficult)
exactly in the middle for the Xaw3d one.  (I do not know about the
other varieties of scrollbars.)  This mainly matters in large buffers.

The best solution may indeed be to either only use mouse-2 for
dragging in large buffers if you do not mind about the initial
scrolling or be very careful about where you grab the slider.

In the case of the native scrollbar, the documentation string you get
from C-h k and then clicking mouse-2 on the slider still misleadingly
suggests that scrolling only takes place if you click *outside* the
slider, whereas it happens regardless of where you click (except at the
very top, where the top still winds up where you click, except that it
is already there).  The documentation you get in the same situation
for the Xaw3d scrollbar throws me off completely.

Unless the behavior itself would be changed I suggest to replace, the
current documentation string for `scroll-bar-drag', namely:

"Scroll the window by dragging the scroll bar slider.
If you click outside the slider, the window scrolls to bring the slider there."

By something like:

"Scroll the window to bring the slider to where you click.
You can then subsequently scroll the window by dragging the slider."

If this is intended for general scrollbars, not just the native one,
we can not be more specific and say which part of the slider gets
moved to where you click.  If the user cares, he will just have to try
it out to see.

This would only help the native scrollbar.  The C-h k output for the
Xaw3d case seems strange.

Sincerely,

Luc.

Re: scrollbar (again)

[Luc Teirlinck]

>From my previous message:
   
   Unless the behavior itself would be changed I suggest to replace, the
   current documentation string for `scroll-bar-drag', namely:

   "Scroll the window by dragging the scroll bar slider.
   If you click outside the slider, the window scrolls to bring the
   slider there."

   By something like:

   "Scroll the window to bring the slider to where you click.
   You can then subsequently scroll the window by dragging the slider."


Or maybe:

"Scroll the window by dragging the scroll bar slider.
Initially, the window scrolls to bring the slider to where you click."

That way the main purpose still appears in the first line and the
second line makes clear that some initial scrolling is to be
expected. 

Sincerely,

Luc.

Re: scrollbar (again)

[Stefan Monnier]

> For the no-toolkit scrollbar the *top* of the slider (thumb, whatever)
> moves to where you click with mouse-2.  In the case of the Xaw3d
> scrollbar the *middle* moves to where you click.

I use the following resource to change it back to the way Xaw behaves:

	*Scrollbar.pickTop:     True

The problems you're discussing are all due to the fact that if we use
the Xaw3d scrollbar or the Motif scrollbar or the GTK scrollbar or ...,
it implies a particular behavior over which Emacs has very little control.
OTOH you have the advantage that the key bindings are the same as the ones
used by other applications (as long as they use the same toolkit).


	Stefan

Re: scrollbar (again)

[Luc Teirlinck]

>From my earlier message:

   Result of C-h k and click with mouse-2 on the thumb of the Xaw3d
   scrollbars:

   <vertical-scroll-bar> <mouse-1> (translated from <mouse-1>) runs the
   command scroll-bar-toolkit-scroll
      which is an interactive compiled Lisp function in `scroll-bar'.
   It is bound to <vertical-scroll-bar> <mouse-1>.
   (scroll-bar-toolkit-scroll EVENT)

   Not documented.

   Comment: mouse-1?  Is this normal?  I definitely clicked mouse-2.

Is this because it is not Emacs itself that handles the click?  Does
this mean that there quite simply is no way to give meaningful C-h k
documentation to the user for non-native scrollbars in this situation?
(The same happens for mouse-3 in the Xaw3d scrollbar.)

Sincerely,

Luc.

Re: scrollbar (again)

[Stefan Monnier]

> Is this because it is not Emacs itself that handles the click?  Does
> this mean that there quite simply is no way to give meaningful C-h k
> documentation to the user for non-native scrollbars in this situation?

Yup,


	Stefan

Re: scrollbar (again)

[Luc Teirlinck]

Mouse clicks in the scrollbar not handled by Emacs seem, at first
view, all to invoke `scroll-bar-toolkit-scroll', an undocumented
function.  (At least for Xaw3d.)  Would it not reduce the confusion of
the C-h k user if we gave `scroll-bar-toolkit-scroll' some
documentation string, explaining that it can get invoked by various
mouse clicks in the scrollbar over which Emacs has no control?

If one would do that, one could even correct the typo just above it:

;;; Tookit scroll bars.

(I believe I am getting into the real trivial nit-picking here.)

Sincerely,

Luc.

Re: scrollbar (again)

[Robert J. Chassell]

   (I believe I am getting into the real trivial nit-picking here.)

No, this is actually critical.   Good, accurate, and complete
documentation is essential.

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

Re: scrollbar (again)

[Luc Teirlinck]

I meant that pointing out the small typo in the comment was
nitpicking.  Not trying to get accurate C-h k output.

Sincerely,

Luc.

Re: scrollbar (again)

[Miles Bader]

On Fri, Mar 28, 2003 at 05:00:59PM -0500, Stefan Monnier wrote:
> > Is this because it is not Emacs itself that handles the click?  Does
> > this mean that there quite simply is no way to give meaningful C-h k
> > documentation to the user for non-native scrollbars in this situation?
> 
> Yup,

Incidentally, does anyone know if it's possible to customize GTK's scroll-bar
behavior?  I'd actually rather like to have the traditional emacs behavior
rather than the (IMHO wretched) apple/windows behavior.

Thanks,

-Miles
-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin

Re: scrollbar (again)

[Luc Teirlinck]

Miles Bader wrote:

   Incidentally, does anyone know if it's possible to customize GTK's
   scroll-bar behavior?  I'd actually rather like to have the
   traditional emacs behavior rather than the (IMHO wretched)
   apple/windows behavior.

Is C-h i g (emacs)GTK resources sufficient?  If not there are some
links to more (actually very) detailed stuff there.

Sincerely,

Luc.

Re: scrollbar (again)

[Jan D.]

> On Fri, Mar 28, 2003 at 05:00:59PM -0500, Stefan Monnier wrote:
> 
> Incidentally, does anyone know if it's possible to customize GTK's scroll-bar
> behavior?  I'd actually rather like to have the traditional emacs behavior
> rather than the (IMHO wretched) apple/windows behavior.

Exactly what is the difference?  I don't know what "apple/windows behavior"
means.

	Jan D.

Re: scrollbar (again)

[Miles Bader]

On Sat, Mar 29, 2003 at 08:58:51AM +0100, Jan D. wrote:
> Exactly what is the difference?  I don't know what "apple/windows behavior"
> means.

The `apple/windows' behavior is that the meaning of scrollbar clicks depends
on whether they are before/after/in the thumb, which results in confusing
behavior when the thumb moves past the click point (something which happens
quite often in practice).

The `emacs' behavior is that the meaning depends strictly on which button you
use, and to a lesser extent where exactly in the scrollbar as a whole.

-Miles
-- 
Would you like fries with that?

Re: scrollbar (again)

[Jan D.]

lördagen den 29 mars 2003 kl 17.03 skrev Miles Bader:

> On Sat, Mar 29, 2003 at 08:58:51AM +0100, Jan D. wrote:
>> Exactly what is the difference?  I don't know what "apple/windows 
>> behavior"
>> means.
>
> The `apple/windows' behavior is that the meaning of scrollbar clicks 
> depends
> on whether they are before/after/in the thumb, which results in 
> confusing
> behavior when the thumb moves past the click point (something which 
> happens
> quite often in practice).
>
> The `emacs' behavior is that the meaning depends strictly on which 
> button you
> use, and to a lesser extent where exactly in the scrollbar as a whole.

Ah, I rather think of it as "Xaw versus the rest" as Qt, GTK, Motif, 
Apple
and so on behave the same.  The GTK scroll bar can not be changed
without rewriting the code for it.  The buttons and actions are quite
hard coded.

	Jan D.