Richard Stallman <rms@gnu.org> writes:

>     IIRC, the scroll bar callback is invoked with action information only,
> 
> Could you explain what "action information" means?

I meant "user action".  In the Motif case, for example the scroll bar
callback in invoked for user action meaning "line down", "page up" etc.

> (I'm assuming you are the expert on this--wasn't it you who
> wrote that code?  If I should ask someone else instead, please
> tell me who.)

I wouldn't call myself an expert on this stuff.  Stefan, BTW, also
worked on the scroll bar code.  He probably knows at least as much
about this as I do.

>     See, for instance, the LessTif/Motif callback xm_scroll_callback in
>     xterm.c.  AFAIK, the callback cannot tell which user actions caused
>     the action, i.e. up/down events etc.
> 
> I see one "action" is XmCR_DRAG.  Can you find out, and tell me,
> exactly when that is given? 

The only info I have is a man page.  I'll attach it at the end.

> Is it for the down event on the slider, or for an up event after
> sliding the slider, or what?

As I read the man page, XmCR_DRAG is received while the user is
dragging the slider for "each incremental change of position", so it
would be neither up nor down event.

> 
> What does a callback with that code signify?
> 
> I noticed that xm_scroll_callback calls x_send_scroll_bar_event:
> 
>     /* Send a client message with message type Xatom_Scrollbar for a
>        scroll action to the frame of WINDOW.  PART is a value identifying
>        the part of the scroll bar that was clicked on.  PORTION is the
>        amount to scroll of a whole of WHOLE.  */
> 
>     static void
>     x_send_scroll_bar_event (window, part, portion, whole)
> 
> I don't understand the role of this function in the overall
> implementation of toolkit scroll bars.  Could you explain it?
> 
> It seems to be sending some sort of X event to Emacs's X window.
> Why is that?  What happens when that client message "arrives"
> again?  Which part of the code in Emacs handles it then?
> And why not call it directly instead of sending a message
> to the X server?

I've used x_send_scroll_bar_event to "translate" the invocation of the
scroll bar callback to an X event that is handled in XTread_socket
like other events.  This seemed to be the easiest way to orderly
produce a scroll bar input event in the kdb queue because I saw no way
to predict when the callback is called (asynchronously).